Virtual Memory concerns

[blue&whiteman]

I was running a few apps this morning and my computer had not been rebooted for a good 24 hours, did a vm_stat in the terminal and to my shock my hit rate was a very respectable 12%. nice number considering I only have 512MB RAM.

About an hour ago I did another vm_stat check it it was at a whopping 62%, what the heck??? I did a reboot but even right after that it was still in the 50%. Till now it was never higher than about 35%.

Can someone help me understand why it would ever get to 62% especially after a reboot. I got better numbers than this when I only had 256MB. I was not doing anything out of the ordinary and now every time I check it its at least 53% or higher! I don't get it!

 

[ksz]

Re: Virtual Memory concerns

The Hit Rate reported by vm_stat might not be a good indicator of low memory. It's not clear what this hit rate means: it's the percent of object lookups that succeeded (i.e. objected being looked up that were already available in the object cache).

In any case, I would suggest looking at some other statistics reported by vm_stat. First, most VM systems on UNIX operate like this (with some variation between implementations):

An algorithm calculates the real-time memory demands facing the system and sets a "page clock" to an appropriate frequency.

The higher the demand for memory, the higher the clock frequency. If the algorithm determines that memory demands on the system are very low, the clock is (momentarily) stopped.

At each tick of the clock, an algorithm goes thru the active pages and places the least recently used (LRU) pages on the free-list or inactive list. The algorithm takes a number of factors into account when determining whether to inactivate a page.

Pages on the free-list or inactive list are not paged out to disk right away because that would incur the expense of disk I/O. Even if the pages have been modified (i.e. dirty bit set) they are not paged out.

When a process references a page, and that page is on the free-list, the page is reactivated (removed from the free-list and marked as active). This is reported as "Pages reactivated".

When memory begins to run low, the space used by pages on the free-list has to be reclaimed. At this point selected pages are written out to disk (paged out) and active pages take their place in main memory.

Hence, the most significant measure of low memory is the Page Out statistic, particularly as a fraction of Page In. You should also look at the "Pages free" statistic.

The output below is from my system, and shows a 42% hit rate, but 0 page outs and 144,041 free pages. In effect, there is no memory shortfall.


Mach Virtual Memory Statistics: (page size of 4096 bytes)
Pages free: 144041.
Pages active: 36810.
Pages inactive: 58919.
Pages wired down: 22342.
"Translation faults": 938219.
Pages copy-on-write: 37205.
Pages zero filled: 353293.
Pages reactivated: 0.
Pageins: 27650.
Pageouts: 0.
Object cache: 10357 hits of 24347 lookups (42% hit rate)

 

[blue&whiteman]

I just did a reboot and all I opened before these stats was the terminal itself.

Mach Virtual Memory Statistics: (page size of 4096 bytes)
Pages free: 88384.
Pages active: 18250.
Pages inactive: 13271.
Pages wired down: 11167.
"Translation faults": 178905.
Pages copy-on-write: 18900.
Pages zero filled: 51326.
Pages reactivated: 0.
Pageins: 10827.
Pageouts: 0.
Object cache: 4766 hits of 6669 lookups (71% hit rate)


I hope this helps people understand what the problem would be. its mind boggling that I would have a 71% hit rate right after a reboot!?!

 

[ksz]

What do you think the Hit Rate is, and why do you think a high rate is worse than a low rate?

In most cases, higher cache hit rates are BETTER. It means the information the system is looking for is already in the cache. In this case, like I said, I don't know what cache is being referred to, but let's say it's the L2 cache. In that case, a high L2 cache hit rate is definitely a good thing!

 

[blue&whiteman]

oh, I thought that the higher the hit rate the worse it was. I have 1MB L2 cache by the way.