hutch@fps.com (Jim Hutchison) (10/11/90)
In <1990Oct09.121447.3336@virtech.uucp> cpcahil@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