Mountain Lion seems to have addressed the memory management issues in OS X (opens in new tab)

It is definitely better overall with ML in that it is no longer ridiculously slow but memory consumption for typical set of tasks still is way higher than either of Linux and Windows.

For instance I have KDE4 running on Linux with Firefox, Amarok, Kopete, Konsole and all other default services (ssh etc). Used memory is 1.1GB.

I've ML running with Firefox, Terminal.app, Activity Monitor in addition to the defaults. Any my used memory is 3.92GB. Wired is 1.75GB and Swap used is 11MB!

My experience with Windows 7 is also lot better than ML - it tends to be bit more than Linux but in the same ballpark.

Edit: To put this in perspective - I just realized that my work laptop (that I RDP into and never reboot) with all possible bloatware loaded and running - Word, Outlook, RDP, Lync 2010, Java Backup process, Enterprisey stuff, Firefox with couple tabs etc. is taking up only 2.83 GB! Apple really has a memory usage problem with OS X.

Unused memory is wasted memory. As a user, you shouldn't care about memory usage if there's plenty available.

It's far more interesting to see what happens in a low-memory situation.

A lot of that memory is shared memory.

What's the problem with the OS and apps using as much available memory as possible?

That's child's play. Open Dashboard and watch the horror.

Is that Virtual Memory? Or Private / Reserved / Shared?

On a new rMBP with 8GB RAM, running eclipse, iTunes, weka (ML software), kindle reader, open office, safari, preview with a half dozen pdfs open, terminal. 5.5 GB used, 0 pages out:)

I'm running programs of similar functionality but coming in at 1.95GB.

Chrome (only 8 tabs right now), Rdio, Sparrow, Coda, Terminal, Notational Velocity.

That's not what pageouts as reported by OS X refer to. Try the following experiment:

  1) Open two Terminal windows.
  2) Run top in one of them.
  3) Note the pageout number.
  4) In the other, type echo foo > bar.txt
  5) Refer again to pageout number.

You will see that it did not increase, even though the system just wrote to a file. This will be the case even if you wait a while.

On OS X, the reported pageouts are dirty memory pages being tossed, not writes of files to the filesytem.

Your definition also does not match the historical distinction between swapping and paging and the distinction you draw is idiosyncratic. Originally, swapping referred to swapping out all of a process's memory, while paging is done in chunks. No system has true "swap" in this original sense any more, so the terms "swap" and "page" are now basically interchangeable.

Where did all of that come from? It's fantasy as far as I can tell.

I have never heard "Page-outs refer to a file-backed page being committed to disk."

I think you are confusing it with a file cache or buffer cache commit interval.

A page out is when a page of memory is written to disk ("paged out") so you can use more live memory than you have physical RAM. Fun fact: the kernel is smart enough to not page out the page in code.

Dredging up my knowledge from OS class, there are three sections of memory for a (Von Neumann architecture) program: the data section (also called the program section), the stack, and the heap.

The data section is the actual compiled bits of the program: the machine instructions themselves. The stack and heap are memory used by the program at run-time.

Completely separate from that, on a Linux system, there is the VFS buffer-cache system. When you write to a "file", you are actually writing to VFS buffer cache memory, and the OS then flushes that dirty page of VFS cache to disk, at which point the write is committed.

Your description of page-outs sounds as though you are describing the operation of the VFS buffer cache flushing its dirty pages to disk.

In my college education (1998 to 2003), we used the terms swap-out and page-out interchangeably.

However, I have heard some people make the distinction of using page-outs/ins to specifically refer to just the data section of an app being written to / read from disk, with term swap-outs/ins referring to the same operation on the stack and heap.

But I've never encountered the term "page-outs" being used to refer to dirty file-backed storage pages being flushed to disk. Is this an old-school hacker thing? Or did I misunderstand and create a straw man?

"to reduce the risk of lost data in the event of a power outage"??

Doesn't sound right to me; if the power goes, you're rebooting into a fresh memory image, not recovering to the memory state in the current pagefile.

Eagerly synching back to disk is surely more about making sure you have a minimal amount of dirty pages in RAM at any time, so that in the event that you need to use a lot of RAM for something else you don't have to wait until the backing store updates before the page space in RAM is free... no?

Edit: Oh, I see - you're saying that 'page out' refers to writing a page of data back to disk through a memory-mapped file - it's basically just a disk write, and has nothing to do with memory pages or pagefiles. Hmm... is that terminology distinction universal?

> Every OS guarantees that file-backed pages be committed within some reasonably short period of time

Just curious: is that "short period of time" usually in order of seconds or minutes? (I know different OSes have different defaults; I just want to know a ballpark figure!)

Most modern operating systems try write the contents of the physical memory to the page file at the first good opportunity (well before it's needed) in order to save time when the page is actually paged out, so it's perfectly normal to have a page file that is at least as large as your physical memory.

The size of your page file isn't a sign of a performance problem. What matters is how often your paging out and in between disk and memory. That will result in a huge slow down in human-perceived performance.

The OP (and others, including myself) have observed a noticeable drop in the delays caused by frequent paging in and out. I checked and my pagefile is the same size as on Lion. Perhaps ML is still paging frequently, but if so, they've found a way to do it so that I'm not noticing it. Everything just feels faster compared to Lion.

Are you sure that's not your sleep image?

you sure it's the page file? page file or hibernation (safe sleep) file? Memory swaps to /var/vm/pagefile0 etc....

unless you disabled it deliberately through a 3rd party tool or command line, your macbook will dump all of RAM to disk as soon as it sleeps - this is your "safe sleep" recovery if power drops too low. It doesn't wait around for low power to dump it out, it does it as soon as you close the lid.

Upgraded one machine from Snow Leopard (10.6) and another from Lion (10.7). No issues what so ever. Both still work perfectly, all my stuff from HomeBrew transferred over without any issues either (which is fantastic, did not want to have to recompile all of that stuff).

The upgrade was fast and easy, definitely not something I expected and I had backed up my machine to do an install from scratch, but not required at all.

Clean install is always recommended no matter which OS you're coming from.

I did an upgrade from SL with no issues.

I'm seeing the exact opposite, but for a different reason. On Lion I could put my MBP to sleep and only lose about 5-10% of the battery over 8 hours. Now on ML I lose ~40%, with nothing running. I turned off location services today to see if that's the culprit.

As for actual on-battery use - yes, the battery life is noticeably improved over Lion.

How much did Lion affect it?

This is slightly off topic, but make sure you are on the latest version of Parallels before doing the upgrade. For some reason, Parallels 6, which is less than 2 years old, does not support Mountain Lion. Personally, I do not care about the new features in Parallels 7, but was a bit annoyed when forced to upgrade.

Virtualizers need as much RAM as you can possibly throw at them. Filler up!

Is that memory consumption or i/o contention?

If your VM image is being backed up that could be a problem. I keep my VM images on an external drive mainly for overall i/o performance reasons. They're not backed up but then all the data I care about is still on my main drive and safe. If you can tolerate the risk, you could try excluding the VM image directory from time machine and see if that makes a difference.

I'm sure someone will be along to correct me quick enough if I'm wrong, but last year when I was upgrading to Lion I had the same issue (journaling turned off) and was able to turn it back on with minimal pain by doing it from the Snow Leopard boot disc (Disk Utility, of course).

Just curious: why did you disable journaling?

Does anyone know if there is a way to monitor xcode and find out if it's GC or ARC?

Mountain Lion uses like 300mb more on my Macbook Air (probably some of the new stuff running in the background like Notifications) but I don't feel the difference in performance. It's not much slower or heavier than SL during real world usage. It does on the other hand feel better than Lion (I really had regrets when I first switched to Lion, particularly before the bug fixes). But I don't think Lion's problems had anything to do with ram management. Some of the animations just felt particularly sluggish, even if the computer had lots of ram free, and lots of other little things like that.

By not switching to lion and waiting for ML you dodged a bullet.

I had 4gb up until I upgraded to ML. After 2-3 days on ML I noticed my free memory was around 300mb. I upgraded to 16gb for $65(cheap Komputerbay ram from amazon.com). An 8gb upgrade is ~45 for crucial 1.35V ram. I think its worth it.

What kind of card do you have? Hackintoshing has gotten a lot friendlier in the last few years. I upgraded a hackintosh I built for a friend from 10.6 to 10.8 and was pleasantly surprised by how everything "just worked" with minimal kext juggling.

I'm not so sure. When someone says "the memory management issues in OS X", I feel pretty confident in assuming specifically which problem they are referring to.

There are some memory models which appear to behave in a way which is relatively psychologically pleasing, and some which do not.

When users are using a program, there are certain times when they have a reasonable expectation that the machine is going to need some time to complete a task ("click and wait"). There are other times when they have no such expectation, and if the machine makes them wait, they get annoyed.

It isn't about the total time they have to wait, its about whether that waiting occurs when they expect it to or not.

Further, when they start to experience these unexpected, annoying pauses, they have a certain expectation that adding more RAM to the system should solve the problem, and when it doesn't, their annoyance only intensifies.

Having used both Linux and OS X as a desktop, I'm going to claim that the Linux VM behavior is pleasing in the ways described above, and the OS X behavior is not.

My understanding is that this is due to just one underlying behavior of the VM: When experiencing memory pressure, Linux (generally) favors evicting filesystem cache over swapping out stack/heap memory to disk, and OS X does not.

Really? Because it solved my problem completely. I have to reboot when my system runs out of RAM, but I'd much rather do that once every two weeks than be constantly bombarded with beach balls.

In spite of the fact that it worked for many people?

If you mmap a file, and then access the mmap'ed region, pulling in the pages of the file from disk is considered paging the file in. Watch the output of fs_usage to see examples of this.

No, but that's funny.