Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!maverick.ksu.ksu.edu!brtmac
From: brtmac@maverick.ksu.ksu.edu (Brett McCoy)
Newsgroups: comp.unix.internals
Subject: Re: RAM disk.
Message-ID: <1990Oct9.212050.10801@maverick.ksu.ksu.edu>
Date: 9 Oct 90 21:20:50 GMT
References: <18560@rpp386.cactus.org> <143359@sun.Eng.Sun.COM> <18574@rpp386.cactus.org> <1850@necisa.ho.necisa.oz> <1990Oct09.121447.3336@virtech.uucp>
Sender: news@maverick.ksu.ksu.edu (The News Guru)
Organization: Kansas State University
Lines: 17

In <1990Oct09.121447.3336@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes:

>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.

Could someone tell me if this is possible on a Sun SS1 (increasing or
decreasing NBUF entries) and if so, where it needs to be done?  I looked
in the kernal config files and couldn't really find anything that looked
like it would do the job.
--
Too bad the universe doesn't run in a segmented environment with
protected memory. -- Wiz from "Wizards Bane" by Rick Cook
Brett McCoy                 | Kansas State University
brtmac@maverick.ksu.ksu.edu | UseNet news manager.