System tuning (was Re: RAM disk.)

[Jim Hutchison]

In <1990Oct09.121447.3336 at virtech.uucp> cpcahil at virtech.UUCP (Conor P. Cahill):
>On a system that was running near 90% utilization (i.e. very little CPU 
>left) we doubled the number of NBUF entries and system performance
>*dropped* significantly.  This was probably due to the extra time spent
>searching through the buffer cache looking to see if a block was there.

Hmmm, if you double NBUF you also increase your paging activity due to
your reduced real memory for programs to run it.  This is taken care of
in some systems by having the buffer cache size itself dynamicly.  This
allows you to have a large buffer cache when you can afford to have one.
The trade off between paging and filesystem I/O would seem to be what
the kernel programmer would be tuning for.  Certainly this ratio is harder
to compute accurately when filesystem I/O may be faster/slower than the
paging I/O.  This could be addressed by having devices report their relative
data rates, but perhaps that level of tuning is unnecessary.

>This is an example of why performance tuning is magic.  There are no
>simple answeres for all cases. What seems at first examination to be an
>obvious performance gain, may turn out to be a loss.

Magic?  Well, there are certainly a lot of issues.  Examining the memory
set of your current process mix (max/avg/min), is a bit of a pain to
figure.  I've always done these calculations 'by wire'.  If you've got
lot's of free memory, pump the cache.  If you're paging wildly (and it's
not a case of VM implementation problems), back off the buffer cache so
that more of the pages can stay resident.

Things like RAM disk, tmpfs, delayed-write mount, async NFS, etc. all have
merit in certain lights.

For RAM disk, certainly a program which was written to run out-of-core with
a 65 Mbyte scratch file will run better on a 128Mbyte machine with a 65+
Mbyte RAM disk where the scratch file lives.  Re-write it you say?  That
demand would be best paid for by having the program generate some revenue
first, eh?  Similarly, tmpfs and "delayed-write mount" work well for compiler
temporary files and short transaction type files for things like Mail.

More than hacks, I view them as symptoms of an I/O hungry community that is
growing beyond the current ability to service that need.
--
-
Jim Hutchison		{dcdwest,ucbvax}!ucsd!fps!hutch
Disclaimer:  I am not an official spokesman for FPS computing