[robg adds: I have not tested this one myself...]
|
|
|
I have been using this hint for about a week or two, and believe it's ready for "prime time" on OSX Hints. Credit goes to Charles Richmond, as posted in his Tuning maxvnodes for better performance topic on the Apple Discussions boards.
[robg adds: I have not tested this one myself...]
•
[24,753 views]
Hint Options
Tuning maxvnodes for better system peformance
Wow....this works. I am looking at top running, and it seems that the ram isnt stuck and the pageouts are low.
Tuning maxvnodes for better system peformance
After adding more RAM, this is the single biggest improvement you can make to system performance. If you have more than 500 megs of RAM, try tuning the kernel per this hint. It really works.
Please Explain
could some one explain
Please Explain
Read the thread in the Aplle Discussions. It is all laid out there.
Tuning maxvnodes for better system peformance
Here's some more info about this from this site:
Be VERY careful with dynamic_pager custom settings...
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)
This hint works!
eMac 800Mhz with 512 meg of RAM.
Tuning maxvnodes for better system peformance
Something doesn't jive here though. I am a prime candidate for this - with over 1.2G of RAM. Following the info at the discussions, I tested to see if it would be beneficial using these commands:
First to see if the change will be beneficial, wait unto your system is being sluggish and in a terminal window do the following commands: pstat -T sysctl kern.maxvnodesThe numbers came up almost identical - I think a difference of 1. So I hardwired the tuning to the /etc/rc as explained and then rebooted. Running the test after rebooting and enabling this hack I get:
% pstat -T WOW!... a difference of 6... is that supposed to be good??? I personally have not really noticed any performance increase either.
Tuning maxvnodes for better system peformance
I'm also suspicious about this hint. It seems to me that unless you are doing something that requires an extremely large number of files open at once (or open repeatedly), a very large value of maxvnodes is not going to help. It can even hurt as the ram used to hold all those vnodes could be put to other use.
Tuning maxvnodes for better system peformance
I'm a bit suspicious of this too. I've tried it out and from everything I can tell, the number of vnodes in use will never shrink significantly. I think I only saw vnode shrinkage when I actually deleted recently touched files.
A little convenient script to calculate the percentage of vnodes used
The maxvnodes tip is useful but it's all in the fine tuning. Here's a little script that calculates how many vnodes are used as a percentage of the maximum vnodes. I put it in /usr/local/bin/vnodeusage. I found it invaluable when tweaking the maxvnodes value.
Enjoy!
sh version
Here's an sh version (repeat after me: I will not script in tcsh, I will not script in tcsh...) that uses awk instead of sed:
#!/bin/sh
# returns percentage of maxvnodes used
vnodes=$(pstat -T |awk '/vnodes/ {print $1}')
maxvnodes=$(sysctl kern.maxvnodes | awk '{print $3}')
echo "$(expr $vnodes \* 100 / $maxvnodes)% used"
A little convenient script to calculate the percentage of vnodes used
There is a mistake on the second to last line:
Tuning dynamic_pager so unused swapfiles dissapear
Nice tip! I couldn't get the script to work, I get I have 768 Mb RAM, and my vnodesused=13101, vnodesmax=13104. As soon as I increased kern.maxvnodes=51904 the system started using it, already at 13431 vnodes used in only a couple minutes of running. Well Mac OS X doesn't use sysctl for virtual memory so the sysctl entries: vm.{anon,exec,file}{min,max} (referenced in a link to an email in the page referenced above). I made the following changes to my /etc/rc file:
In case you want to go back, the original statement was:
For a while I tried cutting the swap file sizes in half, because the swapfiles never EVER seemed to dissapear from my /var/vm, however it did not seem to make any difference at all:
By lowering the "highwater mark" to 35000000 from 40000000, now my swapfiles are disappearing once in a while. Most noticeably when I run classic, look in /private/var/vm, then stop Classic. Look in /private/var/vm again. Tada! Note that Apple's dynamic_pager is very poorly documented and I just got lucky with my choice of numbers. Being a crucial component of the OS, dynamic_pager really needs some comprehensive documentation!
Tuning maxvnodes for better system peformance
Oops, I meant to say in my last message:
I couldn't get the script to work, it always says "expr: syntax error". So I just added this before the expr line:
syntax errror
Just add a backslash before the '*' in the expression.
Tuning maxvnodes for better system peformance
On my PBG3 with 384MB I get 99% when I run this script and only have a few (less than 10) programs open. This seems completely unreasonable?
Tuning maxvnodes for better system peformance
OK, Apple seemed to pull this or it is lost somewhere in the discussions. Does anyone have the text from this article? I posted only the link and not the instructions.
Apple thinks secret, but the net never forgets...
As I saw this coming, I kept a local copy, no idea how much of the thread will fit in one comment, here we go, there were more messages in the thread but nothing really brilliant as far as I remember :
Apple thinks secret, but the net never forgets...
Silly question, quite probably - but my rc file doesn't contain the line ConsoleMessage "Starting virtual memory" - it says echo "Starting Virtual Memory" (I'm running Panther). Is it safe to add the extra lines to the rc file just before this line?
Apple thinks secret, but the net never forgets...
Works just fine in Panther. I say "works" meaning it causes no ill effects. Whether it actually does anything is anyones guess. Just a note though - if you are running the default crontasks for os x that run at 3am or so - all bets are off. This process completely whacks out maxvnodes and when you get up in the morning it is ALWAYS at 100%. I guess I shouldn't say "whacks out" what I mean is - it completely obliterates any maxvnodes tuning you have done. Something about touching/accessing hundreds of files so I've read.
pstat -T = 51883 vnodes
I can confirm this. Don't know which script causes this, but I just entered the maxvnodes adjustment, then ran all 3 (daily, weekly, monthly) and now I get:
So... does someone more knowledgable want to comment on what this might mean in terms of performance?
advice from an Apple kernel developer
I found the following discussion in the archives of the Darwin development email list:
http://lists.apple.com/archives/darwin-development/2002/Aug/msg00441.html The writer is/was apparently one of Apple's kernel developers and so presumably knows what he/she is talking about.
Summary: But the downside is that more of your RAM will be used up for this disk caching and thus you will have less RAM available for normal application use. Therefore you should only consider increasing maxvnodes if you always have lots of "free memory" as shown in 'top' or "Activity Monitor", and if you hardly ever get pageouts (also shown in 'top' or "Activity Monitor").
The default value is a compromise that is expected to result in the best overall performance for people using OS X as a "desktop OS" - i.e. for running GUI applications, etc.
Tuning maxvnodes for better system peformance
Well, it would appear that in the Tiger update, Apple has removed "pstat"... is there another way of discerning the state of the inode cache? |
SearchFrom our Sponsor...Latest Mountain Lion HintsWhat's New:HintsNo new hintsComments last 2 daysLinks last 2 weeksNo recent new linksWhat's New in the Forums?
Hints by TopicNews from Macworld
From Our Sponsors |
|
Copyright © 2014 IDG Consumer & SMB (Privacy Policy) Contact Us All trademarks and copyrights on this page are owned by their respective owners. |
Visit other IDG sites: |
|
|
|
Created this page in 0.17 seconds |
|