Thanks to all who responded, most of them suggested:
- Add Memory to this Server -
and
- Remove other processes from this Server -
They were right - this Machine is also acting as mailhost.
Some user processes are running on this machine as well.
So i'll try a memory Upgrade and removing user processes.
Thanks to:
adam%bwnmr4@harvard.harvard.edu (Adam Shostack)
nlf@aluxpo.att.com (Nelson Fernandez)
dsnmkey@guinness.ericsson.se (Martin Kelly)
kwthomas@nsslsun.nssl.uoknor.edu (Kevin W. Thomas)
Christian Lawrence <cal@soac.bellcore.com>
Mike Raffety <miker@il.us.swissbank.com>
stern@sunne.East.Sun.COM (Hal Stern - NE Area Systems Engineer)
cc_gucky@rcvie.co.at (Gerhard Holzer)
--------------------------------------------------
Responses (not all, some were equal):
>From adam%bwnmr4@harvard.harvard.edu Fri Apr 23 17:52:10 1993
I'm not sure if it would be possible, but I would suggest
greatly increasing the memory on the server. This would allow you to
increase the maxusers easily, and also improve performance by allowing
more files to be mapped into memory.
I would try for at least 128 mb, or even 256 probably would
not be pushing it with this server.
--------------------------------------------------
>From dsnmkey@guinness.ericsson.se Fri Apr 23 20:10:41 1993
You say it is an NFS problem yet you check in the VM area !!!!
Anyway, lets suppose that it is an NFS problem that the users are
experiencing. If so, check out NFS performance tuning first.
Just the usual: increase no. of nfsd daemons, add more ethernet
interfaces to the server, some SNC cards, more RAM etc. It looks as
if you're server here should be pumped up to 128 MB ...
............ ........... ..... (and there is a lot more of course)
Also, check that you do not have a physical network problem first !!
Next, check that Online Disk Suite has been tuned properly. Remeber,
it is only useful if you have large contiguous files and little random
access. Note that read/write NFS servers and RDBMS systems are *NOT*
well suited to disk striping due to the randomness nature.
Also, be careful with the interleave value you have set. Set it between
32 and 48 KB. Also, check that the SunOS disk clustering hasn't been turned
OFF ??? I believe that Disk Suite does this. I would experiment with disabling
Disk Striping and adding another IPI controller: 4 controllers is better for
15 disks.
If you are using this Server as a compute server then you seem to be doing
some heavy processing or at least some heavy cache thrashing on the
system. The CPU cache controller is *not* finding the data it needs and must
fetch the data from main memory or secondary cache. This is costing the
CPU a lot of cycles. Since you are running an MP system (2 I presume) try
disabling one of the processors to see if you can prevent this cache miss.
Also, see if you have too many context switches. These are also flushing
out the cache. Also, with the MP system, it is possible that you are getting
some sort of CPU switching as the processes are re-loaded from one
CPU to the other, flushing the cache with each re-load and hence causing
the cache miss.
Your value of 150 for maxusers seems to be adequate for both ncsize
and nclist but the problem with the poor hit rate in the cache may not
be related to either. However, increasing the maxusers value to 200 or
so cannot do your configuration any harm.
--------------------------------------------------
From: stern@sunne.East.Sun.COM (Hal Stern - NE Area Systems Engineer)
the low cache hit rate is only part of your problem, and probably
a small part of it.
the number of system calls indicates that a lot more than NFS
is happening on this server -- probably a fairly heavy user level
process load as well? plus you're paging a bit heavily.
i would:
- move user level work to another machine
- add memory
these might reduce contention for the DNLC cache, increasing
the hit rate implicitly
--hal
Original Posting:
> From sun-managers-relay@ra.mcs.anl.gov Fri Apr 23 17:13:15 1993
> Sender: sun-managers-relay@ra.mcs.anl.gov
> From: Christian.Hnilica@alcatel.co.at (Christian Hnilica)
> Reply-To: Christian.Hnilica@alcatel.co.at (Christian Hnilica)
> Followup-To: junk
> To: sun-managers@eecs.nwu.edu
> Subject: SunOS 4.1.3 NFS Performance Tuning
> Content-Length: 2025
> X-Lines: 65
>
> Hi Managers,
>
> I,m running a SPARCServer 690-120 in the following configuration:
>
> 64 MB Memory
> 3 ISP-80 Controllers
> 15 IPI 1.3 GB disks (5 of them striped with Online Disk Suite)
> Prestoserve
>
> Receiving questions from users ("why is this server so slow ?") i started
> anlyzing this server's NFS Performance.
>
> vmstat -s delivered the following output:
> .
> .
> .
> 825322 pages examined by the clock daemon
> 59 revolutions of the clock hand
> 711150 pages freed by the clock daemon
> 46279819 cpu context switches
> 60764178 device interrupts
> 5902038 traps
> 31049408 system calls
> 7579112 total name lookups (cache hits 47% per-process)
> toolong 767356
>
> HAVE A LOOK AT THE CACHE HITS (47%) !!!!
>
> Reading various Performance tuning papers lead to:
>
> "increase the MAXUSERS value in the kernel configuration file"
>
> Curently MAXUSERS is set to 150 in the config file.
>
> Being careful, i read the SunOS 4.1.3 Release Manual. This specifies
> 225 as maximum Value for Machines with 64MB RAM or less (with the note
> that this setting has been estimated but not fully tested and that a
> kernel may not boot when exceeding this limit :-)
>
> To reach Cache hits > 90% would result in MAXUSERS > 225 !
>
> Still wanting to imcrease the cache hits, i analyzed param.c in
> /sys/sun4m/KERNEL_NAME.
>
> int nproc = NPROC;
> int maxuprc = MAXUPRC;
> int ninode = (NPROC + 16 + MAXUSERS) + 64 + 12 * MAXUSERS;
> int ncsize = (NPROC + 16 + MAXUSERS) + 64;
>
> int ncallout = 16 + NPROC;
> int nclist = 100 + 16 * MAXUSERS;
>
> I suppose i can increase the cache size by changing the ncsize and/or
> nclist formula.
>
> Anybody out, who knows how to increase the cache size (which formula
> to change) ?
>
> thanks
> ------------------------------------------------------------------
> Christian Hnilica ALCATEL Austria AG
> Systemmanager Scheydgasse 41, A-1210 Wien
> Christian.Hnilica@alcatel.co.at Tel: +43 1 27722 2795
> FAX: +43 1 27722 100
> ------------------------------------------------------------------
>
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:47 CDT