Question about vm_stat
In the terminal if I execute vm_stat I get (for example):
Mach Virtual Memory Statistics: (page size of 4096 bytes)
Pages free: 145902.
Pages active: 30946.
Pages inactive: 92262.
Pages wired down: 25802.
"Translation faults": 8054179.
Pages copy-on-write: 45062.
Pages zero filled: 6349559.
Pages reactivated: 0.
Pageins: 12286.
Pageouts: 0.
Object cache: 20994 hits of 37593 lookups (55% hit rate)
This is all well and good. However, I notice that there are a huge number of "Translation Faults" and a large number of Pages copy-on-write. From the manual I get:
Pages copy-on-write
the number of faults that caused a page to be copied (generally
caused by copy-on-write faults).
Does this indicate anything bad or are these typical values?
Mach Virtual Memory Statistics: (page size of 4096 bytes)
Pages free: 145902.
Pages active: 30946.
Pages inactive: 92262.
Pages wired down: 25802.
"Translation faults": 8054179.
Pages copy-on-write: 45062.
Pages zero filled: 6349559.
Pages reactivated: 0.
Pageins: 12286.
Pageouts: 0.
Object cache: 20994 hits of 37593 lookups (55% hit rate)
This is all well and good. However, I notice that there are a huge number of "Translation Faults" and a large number of Pages copy-on-write. From the manual I get:
Pages copy-on-write
the number of faults that caused a page to be copied (generally
caused by copy-on-write faults).
Does this indicate anything bad or are these typical values?
Comments
Mach Virtual Memory Statistics: (page size of 4096 bytes)
Pages free: 33312.
Pages active: 27150.
Pages inactive: 28122.
Pages wired down: 9720.
"Translation faults": 18751279.
Pages copy-on-write: 72642.
Pages zero filled: 17475509.
Pages reactivated: 110441.
Pageins: 23256.
Pageouts: 9390.
Object cache: 21657 hits of 216013 lookups (10% hit rate)
I'm not sure why your hit rate percent is significantly higher than mine.
[ 05-21-2002: Message edited by: Nostradamus ]</p>
My "translation faults" is more than twice j00rs!
1337!
Mach Virtual Memory Statistics: (page size of 4096 bytes)
Pages free: 2796.
Pages active: 70775.
Pages inactive: 120658.
Pages wired down: 18763.
"Translation faults": 19122049.
Pages copy-on-write: 433753.
Pages zero filled: 11772209.
Pages reactivated: 215328.
Pageins: 41007.
Pageouts: 15007.
Object cache: 123754 hits of 173006 lookups (71% hit rate)
Anyway, no, nothing is bad here. Wiring in and out and faulting is all perfectly normal behavior for allocating memory in a dynamic environment, AFAIK. Also, remember that these are *totals* since you machine was last rebooted. If your Mac has been up for weeks at a time, you should expect some mammothly huge numbers.
[ 05-21-2002: Message edited by: starfleetX ]</p>
[ 05-21-2002: Message edited by: Nostradamus ]</p>
<strong>Pages copy-on-write: 45062.
...and a large number of Pages copy-on-write. From the manual I get:
Pages copy-on-write
the number of faults that caused a page to be copied (generally
caused by copy-on-write faults).</strong><hr></blockquote>
"Copy-on-write" is a way to improve performance for data (eg: structures, objects) that is copied. Simply put, the copied data is not actually "copied" in memory, until the "copied" data is modified in some way. So, if an object is duplicated, but neither it nor the copy have been modified, then the data isn't actually "copied" in memory, until one of them gets modified. Thus, "copy-on-write".
<strong>What exactly does the object cache hit rate percent signify? Mine is much lower than both of you all's hit rates.</strong><hr></blockquote>
When an application requests data held in memory, the cache(s) are first asked if they have the requested memory already. If they do, then that's great, and known as a "hit". If they don't, then the data needs to be fetched from RAM, and is known as a "miss". Generally, if your application fetches mass amounts of sequential data, then the cache "hit" rate will probably be pretty high. If memory access is completely unpredictable, then the "hit" rate will be pretty low.
Getting a positive hit in cache is very desirable since the cost of accessing data from memory is quite high in today's world of ever increasing disparity between processor speeds and memory speeds. This is why larger cache memories are desirable today. However, a larger cache also induces a penalty in terms of the time it takes to determine whether the requested piece of data is in the cache or not. But, today, that cost is a relatively acceptable sacrifice since main memory is so much slower.
FYI: I am running a QS 867 with 1.1GB memory.
L2 cache 256K
L3 cache 2MB