RE: Performance question

On Solaris, the kernel variable for the directory name lookup cache size is
'ncsize'. In /etc/system, you might want to try 'set ncsize = 8192' or even
higher. The kernel variable 'ufs_inode' - which is the size of the inode
cache itself - scales with ncsize in Solaris 2.5.1 and later. Previous
versions of Solaris required both to be adjusted independently, but now, it is
not recommended to adjust ufs_inode directly on 2.5.1 and later.

You can set ncsize quite high, but at some point - dependent on the
application - a too-large ncsize will increase the latency of lookups.

Defaults are:
Solaris 2.5.1 -> (max_nprocs + 16 + maxusers) + 64
Solaris 2.6/Solaris 7 -> 4 * (max_nprocs + maxusers) + 320

Actually, if you attend a Sun Performance Tuning seminar, they will emphasize
that maxusers and max_nprocs are really the only two variables you should need
to tune for most applications, since so many other variables are scaled
according to these two. Some version of Solaris greater than 7 is slated to
have only 6 kernel tuneables - total!

Another new tuneable (actually a toggle) in Solaris 2.5.1, 2.6 or Solaris 7 is
the priority_paging algorithm. This is actually a complete rewrite of the
virtual memory system on Solaris. It will page out application data last, and
filesystem pages first, if you turn it on (set priority_paging = 1 in
/etc/system). As you may know, the Solaris buffer cache grows to fill
available pages, and under the old VM system, applications could get paged out
to make way for the buffer cache, which can lead to swap thrashing and
degraded application performance. The new priority_paging helps keep
application and shared library pages in memory, preventing the buffer cache
from paging them out, until memory gets REALLY short. Solaris 2.5.1 requires
patch 103640-25 or higher and Solaris 2.6 requires 105181-10 or higher to get
priority_paging. Solaris 7 needs no patch, but all versions have it turned
off by default.

Hope that helps someone! ;)

> -----Original Message-----
> From: Jon Kay [mailto:jkay@pushcache.com]
> Sent: Thursday, June 17, 1999 4:25 AM
> To: squid-users@ircache.net
> Subject: Re: Performance question
> ...
> Normally, programs don't worry much about putting files in
> subdirectories, but
> most programs work in an environment where they are helped by a cache of
> inodes.
> Such caches typically hold tens of inodes - obviously, rapidly swamped.
> Note
> that you would need an inode cache of size 10,000 to work with Squid.
> That is
> by no means infeasible, but since smaller inode caches have sufficed up
> 'til now,
> most operating systems do not have such a thing. Since bigger caches
> would help
> with browsers, too, there is an incentive for OS vendors to add such
> features,
> just as they have added features to support tens of thousands of TCP
> connections
> for web service.
>
> Jon
>
Received on Thu Jun 17 1999 - 14:10:45 MDT