Page IN vs Page out memory usage

SSD is faster than machnical rotating hard disk, so pageout/pagein activity will also be faster. Not as fast as keeping everything in RAM, but software tends to be greedy and always get bigger as computers are made with more RAM. It seems to be a law of nature :)

Inactive Memory is your cache of recently used code and data. The OS will check there before doing a more expensive I/O to disk (network I/O if it is network attacked storage). Also inactive memory maybe deferred writes to avoid constant waking up of the disk to do periodic writes that wastes battery life. It will consolidate a lot of little writes into larger writes bunched together in time so the disk can stay asleep for longer periods of time, saving power.

If the OS needs RAM it can get it from free or inactive memory, as the are both available. However, if the inactive memory still has data to be written, the OS will need to do I/O first to save the data to disk, then it can reuse the RAM.

Doing a purge just forces all the OS to clean its RAM cache, doing I/O writes if necessary, then put the pages on the free list. The good news, you have lots of free RAM which is great for starting a new app that needs lots of memory and the app or data it needs has not been accessed recently. And you just consolidated a lot of deferred writes in one disk wake up. Bad news, active programs will need to access disk to get data that may have been in the cache you just purged, active programs that were making multiple updates to the same page that was cached will have read it in from disk before continuing.

Depending on what you are about to do, the purge can be good, or it can be a waste. As mentioned, if about to start new apps, it can help those apps by getting the inactive memory cache cleanup out of the way, but that app had better be a very RAM greedy app to justify taking away the cashed pages of all the other running programs.

If you are personally running purge manually every once in awhile, it really doesn't matter. If you write a script or get a utility that does the purge automatically, that is not a good idea. An automatic purge is going to keep waking up the disk using battery life, it is going to cause apps that could have avoided I/O to wake up the disk to get there data. If you have an SSD, you are going to increase the write activity which will shorten the SSD life expectancy. SSD drives have a limited number of writes in them, and then cells die. The drives have complicated algorithms to replace cells that no longer work, but if you write to them enough, you will exhaust the spares. In normal consumer use this is not a problem, but automatic purging just to keep a large free list, and the cache empty is not going to help an SSD.

Again, you doing it manually when you know you are going to start a big app is not a problem, or doing it for fun to see what happens is not a problem. Just do not automate the purge if you own an SSD or a laptop (battery life).

Pagein will not match pageout, as the OS will load the code for a program by paging it into RAM, and since it does not modify the program code, it does not need to pageout the code when done with it. The OS can just forget it and page it back in the next time it needs that code. And paged out memory may not be needed again when a program quits, so it can be forgotten and not paged in again. So do not try to balance pagein with pageout.

With respect to why you would have pageouts if you have free RAM, the pageout/pagein counters are from boot time and you may have had some activity since you booted that did have a need for more RAM than you had at that time. Also, it is possible for a program to map a file into RAM and read it via pagein, then write to it by using pageouts. For most file I/O this is not efficient, but it is an option available to programmers, and a few use it. Pageout/pagein counters are not restricted to just the swapfiles, so this type of I/O will also increment them.

And back to Lightroom app, when you quit, the inactive memory is caching Lightroom code and data in case you want to access it again. The OS does not know what you are going to do next. And the are programs that get quit and restarted frequently, so caching recently accessed code and data is a win for saving power hungry disk I/O and saving SSD writes.

If you really want to get into the black art of disk I/O avoidance, caching, virtual memory, SSD lifetimes, battery savings, etc..., fire up Google and dive in :)

There's no reason to dump the contents of the modified memory, until that physical memory is needed by another application. If you should restart Adobe Lightroom (or pages from whatever application that's in that modified memory), that memory is potentially available. Here's the Apple write-up on memory management (HT1342).

Put more simply, you already "paid" to load that data in memory, and it's not hurting anything to cache it until some other application needs more free memory than is already free, so why go to the extra effort to dump the data? Cache it, on the off chance you relaunch the application.

Note too that OS X can stop and then restart certain quiescent applications; this is the so-called automatic termination feature. Keeping the modified pages around mean those applications — if the memory wasn't consumed by something else — can allow the application to restart more quickly.

Seeing the page-out counts increase (markedly, quickly) can imply insufficient physical memory for the application(s) in use. Though there are other potential triggers for these page outs, such as application memory leaks.

Performance is one of those "it depends" discussions. Having 53 MB of page outs is probably inconsequential. Unless that happens all at once, and right when you need to do something else, and then you might need to increase physical memory, or restructure your workflow to reduce the memory requirements.

As for the effects of these page outs, how long does it take for your system to write 53 MB of data to your disk? That's approximately how long you waited, in aggregate. (Given my experience with software similar to what you're running, you might well have spent more time just waiting for the application to launch, in aggregate. This is part of why Apple is offering SSD and Fusion drives and systems with more memory; faster initial loads, faster paging and swapping, faster I/O in general, and less need to page.)

As with BobHarris, I'd not recommend running the available automatic purging tools. In general, I'd also avoid the add-on performance-optimizing tools, add-on system caching tools and related. Some of those tools might work, but those tools can also completely skew performance in the wrong direction, and various of those tools can and have caused weird system behaviors, and the tools can go sideways after an OS X update.

With regard to the inactive memory, if I have just quit Lightroom for example and the memory is still caching lightroom data in the inactive memory (incase I choose to reopen it) and I open another RAM hungry file that would exceed the total RAM that is free (in the above case 4.42GB) will it release the RAM allocated in the inactive RAM that was caching the now quit Lightroom app? In other words do I actualy have 4.42GB plus whats in the inactive RAM that was caching apps that are no longer running?

Yes.

And if your next app is still hungry after eating the inactive memory, it will start to force running apps to pageout memory it is using to give it over to the new memory hungry app. And if the app is still hungry it will start eating its own memory, by being forced to pageout some of its own pages to give over for the most recent memory requests from the app. When you reach this point, generally your system and the greedy app crawl to a halt.