From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: Tuning Unix for lots of small files...
Organization: Weber State University  (Ogden, UT)
Date: Fri, 11 Sep 92 17:31:02 GMT

In article <1992Sep11.154227.7250@bristol.ac.uk> P.Smee@bristol.ac.uk (Paul Smee) writes:
>(The choice of cross-posting may seem haphazard.  Reason is that I believe
>this is a unix-wizardly question (our Unix guru doesn't know the answer,
>and our set of FM's don't cast any enlightenment), but on the other hand
>I believe that the issue was discussed in news.admin maybe a year ago.)
>
>Anyhow, I have a vague memory of hearing that there is a parameter
>which can be fiddled when doing a vmunix build, which will increase the
>space reserved by the system for caching information about open inodes
>(or dirs, maybe?), and so might improve performance in an environment
>where the system is doing not very much (computationally), but using a
>lot of (small) files to do it.  Can anyone provide enough further info
>to help us find and twiddle this, as that describes precisely the
>situation this little box is in?
>
>My memory suggests that the answer was more-or-less system-independent,
>at least across normal variants of Unix, but if it matters the systems
>we'd be interested in having the answer for are various flavors of
>SunOS 4.[01].*

	You are talking about the directory name lookup cache (dnlc).
There are several magic incantations effecting this, most requiring source:

1.	NC_NAMLEN in /usr/include/sys/dnlc.h is the longest entry name
	that will be cached.  File names in excess of this are never
	cached.  You have to recompile the kernel from sources to change
	this from it's default value on SunOS (15 characters).

2.	The value of integer "ncsize" is used to determine how many of
	these buffers to allocate.  Generally, this is based on some
	formula involving the number of processes/users allowed.  I won't
	give deatils, since they appear to be copyrighted along with the
	rest of the file.

	SVR4:

		/etc/conf/pack.d/kernel/space.c
	
	SunOS:

		/usr/sys/conf.common/param.c

3.	The larger the cache, the more entries supported; however, the
	more entries supported, the more frequent the hash table hits.  If
	you don't fill your cache, or it contains a lot of entries which
	havent been used in a long time, you will get a lot of thrashing
	unless you also increase the hash table size.  This involves the
	recompilation of dnlc from sources after changing NC_HASH_SIZE to
	a larger value (default seems to be 8 on all systems).

4.	If you ask for too much cache, the dnlc will be turned off when
	the kernel alloc fails to get the memory.  If you have high
	values for NPROCS or MAXUSERS, the cache size required will be
	computed larger.  Too large, and caching goes away entirely
	(instead of scaling back, like you'd expect).  Be careful that
	you do not do this.  Since the flag is static to dnlc, you will
	not be able to tell that this is happening other than by inference.


	There are other things you can do to better performance; one is
doing your own user space caching of file contents; this will better the
performance of reads and writes by reducing the number of kernel crossings
and expensive copyin/copyout operations.  Another is to increase the number
of in-core blocks allowed to be hung of a vnode.  This will result in a
larger hunk of the file staying in core (although if you have a small
amount of RAM, this can actually degrade performance).  This is inferior
to user space caching because you still need to copy the blocks across
the kernel boundry, plus it requires source.



					Terry Lambert
					terry_lambert@gateway.novell.com
					terry@icarus.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.

-- 
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------
Newsgroups: news.admin,news.admin.policy