My Original Question:
----------------------------
Dear Sun Performance Experts,
Is there any way to bump up the speed of a Sparc 1+ (running 4.1.2)
applications which need to manipulate 50 MB+ (GIS) files?
We've not had real good luck putting Solaris 2.4 on this
type of machine tho I've heard 2.5 is faster?
We have a very small budget (< $1,000) if there is anything
this inexpensive which might help.
The bottle neck appears to be just Disk I/O. I've looked
at the "Sun Performance Tuning Overview" (December 1993)
but don't know if max users or adb kernel tuning would
do much good in this case (I've included iostat output below
if that helps).
Thanks very much in advance for your advice. I'll post
a summary if it seems relevant.
--Karl
------------------------------
Thank you for your expert help. Here is a summary of the
suggestions:
* Getting a better scsi controller and moving your data disks to it would help.
* SBUS Wide SCSI controller and disk
* Split the disk chain.
* Going to SunOS 4.1.4 will help some.
* Solaris 2.5 will give you - maybe 10 to 20% speed improvement in
some areas; the higher numbers if you have more than one cpu (not
the case for a 1+) where the increase threading has the most effect.
* Weitek CPU - 3x integer performance increase, but put about
50% to 60% increase in overall system performance
and 20% to 30% increase in IO - these are numbers
are vague recollections only.
* Unfortunately, your machine is a Sparc1+, or I would suggest a Weitec cpu
upgrade for $1k. (They are theoreticaly available for Sparc2 and IPX only.)
For $2k you can replace the montherboard to a Sparc2 and also upgrade the cpu to
the Weitec.
* definitely you should pursue a faster CPU.
* We upgraded our SPARCstation 1+ to a SPARC 5 by adding an Axil
motherboard.
* I'd recommend purchasing more RAM. The SS1+ uses standard 32-pin
parity SIMMs. It has 16 SIMMs sockets, which must be populated in
groups of 4, and can use either 1MB or 4MB SIMMs (I'm not sure whether
it can use 16MB SIMMs). I'd recommend purchasing as much RAM as you
can afford, preferably going all the way up to 64MB (or more if 16MB
SIMMs work).
From: Kevin.Sheehan@uniq.com.au (Kevin Sheehan {Consulting Poster Child})
From: Glenn.Satchell@uniq.com.au (Glenn Satchell - Uniq Professional Services)
* Well, using mmap() instead of read()/write() is a good first move. With
only 24MB, you've got to use what you have efficiently.
From: Kevin.Sheehan@uniq.com.au (Kevin Sheehan {Consulting Poster Child})
* If you control the appliction, then I'd suggest using mmap()/msync()/madvise()
to do your access to the files. I have a paper called "Why aren't you using mmap() yet?"
that details the various wins and shows how to use the facilities.
* Striping would surely help, and if you don't control the
application code, tuning maxpgio up to allow more disk I/O to be devoted
to paging will help a bit.
From: penrod@kazoo.er.usgs.gov (Dan Penrod)
From: Gene Rackow <rackow@mcs.anl.gov>
From: John Justin Hough <john@oncology.uthscsa.edu>
From: Paulo Licio de Geus <paulo@dcc.unicamp.br>
From: hurt <hurt@ionet.net>
From: John Valdes <valdes@geosun.uchicago.edu>
From: Kevin.Sheehan@uniq.com.au (Kevin Sheehan {Consulting Poster Child})
From: Ric Anderson <ric@rtd.com>
From: Bert Shure <Bert_Shure%SOLSOURCE@notes.worldcom.com>
From: mike@borg.drss.state.sc.us (Mike Holland)
From: dougj@xray.ufl.edu (Doug Jones)
With many special thanks to Mary Lou Hinman for looking at
and explaining in detail vmstat and iostat output to determine
for this case the first thing to focus on is the CPU.
"You need more cpu power, followed by memory, followed by disk I/O."
From: Mary Lou Hinman <maryh@cea.Berkeley.EDU>
Thanks again everyone.
--Karl
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:57 CDT