Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'Tuning maxvnodes for better system peformance' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Tuning maxvnodes for better system peformance
Authored by: gxw on Jul 17, '03 12:52:05AM

Here's some more info about this from this site:
http://www.netbsd.org/Documentation/tune/5.html

<fair use>
UBC and sysctl (top)

From what I have gathered on a variety of lists, the most commonly "tweaked" part of the system via sysctl is the Unified Buffer Cache (UBC). In a really great email a developer made some excellent recommendations for tuning a system with UBC, this section will peruse that for the example.

Following along with the maxfiles example above, even though there can now be a larger amount of open files, there still may be more that can be done to make the system run faster. Since more files can be opened, it stands to reason that it would be good if the caching were optimized as well. In the case of this machine, there is a decent amount of RAM (256MB) that despite a lot of low level activity (such as editing and small compiles) is not being utilized to its full potential. This means that the buffer cache could probably be expanded, thereby making performance better since more would be in the cache versus rereading from disk. Now, a word of warning, it is of course possible to raise the size to a point where getting a cache hit is taking too long, but as has been well documented, that number seems to be fairly high [1]. So what is the parameter? It is kern.maxvnodes and in the case of this machine, 38k was used which gave a pretty decent performance boost. In general, it has been seen that a kern.maxvnodes operates well when the size is set to between 1/6 to 1/4 of the amount of RAM (depending on what the system is being used for).
</fair use>



[ Reply to This | # ]
Be VERY careful with dynamic_pager custom settings...
Authored by: kupietz on Sep 22, '08 01:20:10PM

Here's a good way to get your computer to sporadically slow to a crawl and then freeze completely, with no beachball cursor, no diagnostic information written to any log file, and with the mouse still responsive, but no way to break the freeze besides a forced reboot: (tested in 10.4.11)

/sbin/dynamic_pager ${encryptswap} -H 1024 -L 8001025 -S 80000000 -F ${swapdir}/swapfile

Can you see what's wrong? -L is 8,001,025 but -S is 80,000,000 (there's an extra 0.) So double check those numbers. It's a *very* odd and tricky problem to troubleshoot. The only indicator you get of the problem is a very brief warning buried in the output when you do a verbose boot.



[ Reply to This | # ]