Question about vm_stat

Posted:
in macOS edited January 2014
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?

Comments

  • Reply 1 of 7
    nostradamusnostradamus Posts: 397member
    He's mine. It's probably typical.



    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>
  • Reply 2 of 7
    ghost_user_nameghost_user_name Posts: 22,667member
    Tee hee... big numb3rs!

    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>
  • Reply 3 of 7
    nostradamusnostradamus Posts: 397member
    What exactly does the object cache hit rate percent signify? Mine is much lower than both of you all's hit rates.



    [ 05-21-2002: Message edited by: Nostradamus ]</p>
  • Reply 4 of 7
    [quote]Originally posted by neutrino23:

    <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".
  • Reply 5 of 7
    [quote]Originally posted by Nostradamus:

    <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.
  • Reply 6 of 7
    airslufairsluf Posts: 1,861member
  • Reply 7 of 7
    neutrino23neutrino23 Posts: 1,522member
    Many thanks.



    FYI: I am running a QS 867 with 1.1GB memory.

    L2 cache 256K

    L3 cache 2MB
Sign In or Register to comment.