mad jew said:
The system assigns a portion of your hard drive to page ins and page outs. This is called Virtual RAM and can be read in Activity Monitor. Mine is 7.3GB which is about normal. It is this Virtual RAM that is the reason behind keeping at least 8GB of free space because you don't want the system having to cut back on Virtual RAM simply because you don't have the space. 🙂
We don't want to clear Inactive RAM (I don't know how, but Google may help) because theoretically it can potentially be faster than Free RAM assuming you do the same tasks often. If you don't do the same tasks often, then it'll get reassigned to another task. 😎
In terms of memory, all we have to worry about is that free space on the hard drive and the rate at which page ins and page outs accumulate. If the system is acting sluggish then check that you're not getting massive amounts of Virtual RAM usage (restart to reset the counter) and check to see you have lots of free space. 🙂
The number you see in the Activity Monitor for 'VM Size' has
nothing to do with how much space on your hard disk is actually being used for the purposes of the Virtual Memory Subsystem. One must remember that the Virtual Memory system of MacOS X is little like that of Classic.
I can, for example, write a very small application that will increase the 'VM Size' figure by no less than 2 gigabytes, but the free space on my hard disk will remain completely unaffected. I could then run multiple copies of this program, boosting the 'VM Size' by gigabytes and gigabytes; still the amount of space on my disk used will remain unaffected.
I can also write a tiny program that will generate lots and lots of pageouts. All I have to do is allocate a huge address space (about two gigs) and start writing random data to it. Once the program exits, i'll have a huge pageout count but won't necessarily be consuming a lot of memory.
'VM Size' is a record of the total size of the
Virtual Address Space. Disk space is not needed until allocations across the Virtual Address Space occur, and then they are handled on a page-by-page basis (a page being 2 kilobytes, IIRC). A process called the
dynamic_pager is responsible for creating and managing the files that will contain these pages. In its default configuration, the dynamic_pager creates these
pagefiles in 64 megabyte chunks, but if the demand is high enough it will increase that increment by factors of two until the systems paging requirements are satisfied. Thus, one might have four pagefiles on their system: two at 64 megabytes, one at 128 megabytes, and a fourth at 256 megabytes. It is possible to alter the configuration of the dynamic_pager to alter how these files are created and managed, but this requires some technical knowhow and modification of system files.
The pagein and pageout counters are cumulative over time, and never go down. I wouldn't use them as an estimate as to how many memory pages are actually paged out to disk, nor if it means you need to invest in more memory. Indeed, as mentioned before, what is more important is the rate of pageouts. If you are paging out a lot under a normal workload, its a probably a good idea to invest in more real memory.