From: alan@nabeth.enet.dec.com (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
Newsgroups: comp.unix.ultrix
Subject: Re: Why is 5000 SOOO SLOW
Date: 7 Oct 92 18:29:34 GMT
Article-I.D.: nntpd2.1992Oct7.182934.23987
Reply-To: alan@nabeth.enet.dec.com (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
Organization: Digital Equipment Corporation


In article <1992Oct7.090630.1973@doug.cae.wisc.edu>, seaney@engr.wisc.edu writes:
> 
>We have a lab with a Decstation 5000/125 and Dec 5000/200.  Both machines have
>32Meg of Memory (recently upgraded from 16Meg) and about 3Gig of disk.  The
>disks are nfs 'cross' mounted through nfs.  The eithernet link between the
>machines is relatively quiet.  
>
>The workstations are used to run Ansys -- a commercial finite element package
>that eats up a ton of CPU time and creates huge files (100+ Meg). The Ansys
>runs can easily take 2 to 12 hours to complete.  We need to reduce the time on
>the jobs.
>
>I recently had the opportunity to try a few Ansys models on comparable Sun and
>HP workstations.  Both machines  beat the DECStations by over 25%. Is there
>something I can do to increase the performance?  I haven't done much kernal
>tuning on the DECStations, is there something I can change?

The first and sometimes hardest part is identify where the performance
problem is.  Given the configuration information you've provided it
could any of:

1.  CPU performance.
2.  Network performance, probably NFS related.
3.  Local disk I/O performance, perhaps related to paging, perhaps
    do the file I/O that Ansys does.

While one of the Ansys models is running, do a detailed examination
of the performance using iostat(1), vmstat(1) and netstat(1).  If
you have it, Monitor can be useful because it puts all the information
in one place.  The sorts of things you want to look for are:

1.  Enough memory?  If the system is paging, that will slow it down.
    You can get some performance improvement by splitting the paging
    I/O between multiple disks and controllers, and maybe using a
    larger "swapfrag" size.  Enough memory to avoid paging is always
    the better bet.

2.  NFS I/O.  It is mostly reads or mostly writes?  Does the application
    make good use of the buffer cache on the server?  Assuming you have
    ULTRIX V4.2 about the only I/O tuning you can do is get Prestoserve,
    or faster disks.  Striping can help some, because it will spread the
    I/O load over multiple disks.  See your DEC sales person about the
    Striping driver available through our ASSETS program.

3.  Local disk I/O.  Does the application make good use of the buffer
    cache?  Would a bigger cache help?  Would smaller cache give back more
    memory to reduce paging?  As for #2, there isn't much I/O tuning
    you can do on V4.2 expect get faster disks or spread the I/O around
    if it tends to keep one disk busy.

If the bottleneck is I/O (NFS or local file system) the enhancements
in V4.3 may help a lot.

>
>We are considering upgrading to faster machines.  I like DEC -- what can
>account for this performance difference?  Is the SCSI bus on DECstations less
>efficient?
>
>Will the alpha really be that much faster?

The CPU certainly will be, but if the CPU is waiting on data, or
page faults it spends about the same amount of time waiting.  A
faster CPU can speed up I/O only so much, when the I/O subsystem
is close to it's limit.

>
>I'd love a response from inside DEC.  
>
>Thanks a lot!
>Steve
>
>System Administrator
>Department of Mechanical Engineering
>Univ of Wisconsin -- Madison
>
--
Alan Rollow				alan@nabeth.cxo.dec.com
Newsgroups: comp.unix.ultrix