Macos – Why OS X use swap when there is lots of “inactive memory”


I am using OS X from few months (Lion and now Mountain Lion). I have 8 GB on my mini and almost daily now it get close to that. On Windows 7 machine with 8 GB I never had that kind of problem. Anyway, I read over the net, that the inactive memory is app cache of the programs that are recently closed and can be used for faster reopening.And this inactive memory can be released to a new app if needed. It is not released. Instead OS X starts swapping. So my question is why OS X use swap when there is lots of "inactive memory"? Here a screen that shows what I mean:

enter image description here

I really hope there is a away to make OS X to use those 2.69 GB before start swapping.I really do.

Best Answer

The swapping apparently happened when the inactive RAM pages were actually active.

(Update: as it was clarified in a comment, this is not your case. So people with the same problem can skip forward to the horizontal rule.)

I.e. you had many programs running and the kernel swapped-out some pages. Then you quitted some programs. The kernel marks their RAM pages as inactive. But it won't swap-in pages back to RAM until these pages are needed. This results in having both inactive and swapped-out pages.

Why not preemptively swapping-in pages? Because that would be betting against the odds: in the long-run you lose. Let's think of a simplified example: Two programs A and B that don't fit in RAM at the same time. Program A is still running and all the swapped-out pages belong to A. Program B has quitted and all the inactive pages belong to B.

If kernel preemptively swaps-in A's pages and imediately after:

  • program A needs to access it's pages -> You win - the pages are already in the RAM.
  • you launch B again -> You lose - you "paid" the cost for bringing the pages to RAM and now you have to send them back.
  • you launch another program C -> You lose if A and C don't fit in the RAM at the same time. If they fit, you are even.

Also take into account that swapping-out (writing to disk) is more expensive than swapping-in (reading from disk). Which makes this "bet" even more unatractive.

In short: trust your kernel and don't try to outsmart it.

Update: Turns out that inactive memory doesn't work as the Using Activity Monitor to read System Memory article has led many people to believe it works. The definition given in the article for inactive memory is correct:

This information is in RAM but it is not actively being used, it was recently used.

But the following example is totally misleading and over-simplified (like my example to be frank):

For example, if you've been using Mail and then quit it, the RAM that Mail was using is marked as Inactive memory. Inactive memory is available for use by another application, just like Free memory. However, if you open Mail before its Inactive memory is used by a different application, Mail will open quicker because its Inactive memory is converted to Active memory, instead of loading it from the slower drive.

I searched for more online resources and ended up to this thread in the darwin kernel mailing list which is quite informative. Quoting Jim Magee (from the darwin team - I think):

In short, the kernel VM system when dealing with memory pressure scans through in-use pages and tries to keep them in a balance between active and inactive markings. The inactive pages are scanned for reuse while marked as inactive. If they have been reused, they are marked as active and some other page must move from active to inactive state to detect if it is in active use. So, inactive is a misnomer. It is shorthand for "possibly inactive, lets try to verify that."

As you discovered, the internal balance we (currently) strive for is approximately 2/3 active vs 1/3 inactive...

This explains the behaviour you observe. I.e. the inactive pages you see belong to running programs which haven't been recently used. So, when you fire-up a new program, inactive pages are swapped out. At the same time pages from other programs are marked as inactive to maintain the 2/1 ratio of active vs inactive.

The thread also contains some suggestions to learn more about the darwin internals. There are also some suggestions in case you started investigating the memory usage because of beachball problems (which usually have little to do with it).

The conclusion remains the same: Trust your kernel and don't try to outsmart it. :-)