It's important to get the terminology correct when discussing VM behavior. Page-outs are not identical to swap-outs. And unfortunately, due to the age and architecture of the Mach kernel, there's no way I'm aware of on OS X to measure the rate of the latter.
Page-outs refer to a file-backed page being committed to disk; these are perfectly normal and expected (program writes to a file, kernel eventually commits to disk). Every OS guarantees that file-backed pages be committed within some reasonably short period of time to reduce the risk of lost data in the event of a power outage (the sync interval).
A high page-out rate doesn't necessarily imply memory pressure; it may simply mean some program running on the system is writing to files frequently. However, memory pressure may temporarily increase the page-out rate if the sync interval hasn't yet kicked in.
Swap-outs, on the other hand, relate to anonymous memory pages (i.e. the heap). Swap-outs, in contrast to page-outs, are generally bad and indicate severe memory pressure.
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!)
I still ended up with an 8 GB page file after a few days of regular usage (nothing too hard like VMs or anything - just your typical Xcode dev workflow, including opening up Photoshop once or twice to export graphics).
This is on a MBP with 8 GB RAM.
I never had any memory-related performance issues in Lion, (maybe because I have an SSD), but I always end up with a big pagefile of stale data.
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.
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.
It seems as though a lot of people are noticing some speed enhancements. I haven't quantified any of it, so my experience is all anecdotal, but I definitely notice the boost as well.
The changes in Mountain Lion have been subtle, but I really love the upgrade. I performed a full disk backup which took the longest amount of time. The actual install (2012 MacBook Air) took like 15-20 minutes. If anyone is in doubt, definitely do yourself the favor and upgrade. Typically I am hesitant to do major OS upgrades due to things like python or ruby breaking most of my local websites ... everything works great!
I had to modify some apache2 settings (I use the built-in webserver for PHP development) but that was about it. Oh also, apache is still there. A lot of people think that it's gone because the preferences pane is missing, but it's still hiding within the belly of the beast.
I feel like I can throw anything at this. I've never multitasked like this before.
One of the things I've noticed is that the new Xcode 4.4 (released the same time as Mountain Lion) seems to be an awful lot snappier to me. My theory is that this is happening because they might have switched Xcode from being garbage collected to ARC (since it used to be GC ever since Snow Leopard came out but GC is now deprecated).
Haven't seen the paging issues Adam was noticing, but I'm still gobsmacked by the amount of memory some applications seem to take. The OS (kernel_task, mds, WindowServer, and friends) regularly eat up .75 of a gig, and Firefox consumes .5 - 1 gig without much effort (other browsers seem to have a similar profile).
Quick poll, what are you running, and what's your memory consumption? Here's me:
Currently running: Firefox, Spotify, Mail, Calendar, Terminal, Mongo (mongo using 100mb).
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.
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 can concur with OP. My MacBook Pro suffered severe paging issues under Lion, but seems to be (mostly) gone in Mountain Lion. Running Eclipse, Photoshop, Chrome, and Parallels at the same time is possible once again without major slow down on my machine. As always, YMMV.
Odd. I had this problem in 10.6 (Snow Leopard) and it went away when I upgraded to 10.7 (Lion). The most obvious symptom is the machine does not seem to be able to make use of the inactive memory (the blue slice of the pie in Activity Monitor). I did not notice the problem at all when I first started using 10.6. When I hunted around on the help forums a few months ago I found lots of users with the symptoms, but nobody acknowledging the "validity" of the problem. In fact a lot of deniers out there. I wonder if it was quietly fixed or will recur after the system gets used for a while.
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).
Since the GM, I also noticed this on my production machine. Previously I had custom settings for the dynamic pager, but it seems that is not longer necessary.
Subtle changes and I'm happy with them. Probably the next year, we'll see some subtle improvements on the backend.
This is the reason I installed Mountain Lion. I've only used it a bit in the last few days, but I haven't seen crazy amounts of mds RAM usage since installing either.
Only thing holding me back from upgrading is the complete lack of wanting to hex edit my ATI kext again.. heck it might not even be compatbile with ML.
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.
Yup, memory management seemed to be fixed as of 10.7.4 even.
I've found new bug in ML, whenever I switch users, Mountain Lion seems to think I've a desktop much smaller than what I actually have. And sometimes the "virtual" desktop isn't even positioned at 0,0 on my actual desktop. :-/
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.
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.
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.
It's much, much worse for me. Things go into Inactive memory, which is fine, but then it doesn't get freed when it's needed, or else it does so very slowly. So I have 20 MB of Free memory and 4 GB of Inactive and everything slows to an unusable crawl and I have to run `purge` to get my computer to start behaving properly again.
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.
[+] [-] otterley|13 years ago|reply
Page-outs refer to a file-backed page being committed to disk; these are perfectly normal and expected (program writes to a file, kernel eventually commits to disk). Every OS guarantees that file-backed pages be committed within some reasonably short period of time to reduce the risk of lost data in the event of a power outage (the sync interval).
A high page-out rate doesn't necessarily imply memory pressure; it may simply mean some program running on the system is writing to files frequently. However, memory pressure may temporarily increase the page-out rate if the sync interval hasn't yet kicked in.
Swap-outs, on the other hand, relate to anonymous memory pages (i.e. the heap). Swap-outs, in contrast to page-outs, are generally bad and indicate severe memory pressure.
[+] [-] othermaciej|13 years ago|reply
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.
[+] [-] seiji|13 years ago|reply
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.
[+] [-] cellularmitosis|13 years ago|reply
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?
[+] [-] jameshart|13 years ago|reply
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?
[+] [-] pooriaazimi|13 years ago|reply
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!)
[+] [-] kalleboo|13 years ago|reply
This is on a MBP with 8 GB RAM.
I never had any memory-related performance issues in Lion, (maybe because I have an SSD), but I always end up with a big pagefile of stale data.
[+] [-] DrJokepu|13 years ago|reply
[+] [-] kevinconroy|13 years ago|reply
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.
[+] [-] jonhendry|13 years ago|reply
[+] [-] dedward|13 years ago|reply
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.
[+] [-] whalesalad|13 years ago|reply
The changes in Mountain Lion have been subtle, but I really love the upgrade. I performed a full disk backup which took the longest amount of time. The actual install (2012 MacBook Air) took like 15-20 minutes. If anyone is in doubt, definitely do yourself the favor and upgrade. Typically I am hesitant to do major OS upgrades due to things like python or ruby breaking most of my local websites ... everything works great!
I had to modify some apache2 settings (I use the built-in webserver for PHP development) but that was about it. Oh also, apache is still there. A lot of people think that it's gone because the preferences pane is missing, but it's still hiding within the belly of the beast.
I feel like I can throw anything at this. I've never multitasked like this before.
[+] [-] DrJokepu|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] chucknelson|13 years ago|reply
[+] [-] bonch|13 years ago|reply
[deleted]
[+] [-] tambourine_man|13 years ago|reply
“free memory is wasted memory” vs “inactive memory is never released”
“Purge is the worst thing you could do” vs “Purge solves the issue”
We have the kernels's source[1] and DTrace. Let's get some real data?
[1]http://opensource.apple.com/source/xnu/xnu-2050.7.9/
[+] [-] tedsuo|13 years ago|reply
Quick poll, what are you running, and what's your memory consumption? Here's me:
Currently running: Firefox, Spotify, Mail, Calendar, Terminal, Mongo (mongo using 100mb).
Memory Used: 3.75 GB
[+] [-] blinkingled|13 years ago|reply
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.
[+] [-] Zr40|13 years ago|reply
It's far more interesting to see what happens in a low-memory situation.
[+] [-] coob|13 years ago|reply
[+] [-] weiran|13 years ago|reply
[+] [-] joezydeco|13 years ago|reply
[+] [-] malkia|13 years ago|reply
[+] [-] flatline|13 years ago|reply
[+] [-] matthewlyle|13 years ago|reply
Chrome (only 8 tabs right now), Rdio, Sparrow, Coda, Terminal, Notational Velocity.
[+] [-] kevinconroy|13 years ago|reply
[+] [-] T_S_|13 years ago|reply
[+] [-] udp|13 years ago|reply
I can't upgrade yet because I disabled HFS+ journaling and nothing seems to be able to re-enable it (the installer requires journaling to be enabled).
[1] http://d43.me/blog/1205/the-cause-for-all-your-mac-os-x-mous...
[+] [-] evoxed|13 years ago|reply
[+] [-] glhaynes|13 years ago|reply
[+] [-] cicloid|13 years ago|reply
Subtle changes and I'm happy with them. Probably the next year, we'll see some subtle improvements on the backend.
[+] [-] bsimpson|13 years ago|reply
[+] [-] Karunamon|13 years ago|reply
Hackintoshes :/
[+] [-] taude|13 years ago|reply
[+] [-] cydonian_monk|13 years ago|reply
As for actual on-battery use - yes, the battery life is noticeably improved over Lion.
[+] [-] Zirro|13 years ago|reply
[+] [-] Flow|13 years ago|reply
I've found new bug in ML, whenever I switch users, Mountain Lion seems to think I've a desktop much smaller than what I actually have. And sometimes the "virtual" desktop isn't even positioned at 0,0 on my actual desktop. :-/
[+] [-] chiph|13 years ago|reply
Parallels gets abysmally slow for me when TimeMachine starts up.
[+] [-] bchen|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] astrange|13 years ago|reply
[+] [-] cellularmitosis|13 years ago|reply
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.
[+] [-] pooriaazimi|13 years ago|reply
I have zillions of apps open.
It's confusing... If I haven't "swapped out" (page out) anything to disk, then how come I've "swapped in" (page in) 750,000 pages from the disk?[+] [-] achivetta|13 years ago|reply
[+] [-] LoganCale|13 years ago|reply
[+] [-] chatmasta|13 years ago|reply
[+] [-] Nicole060|13 years ago|reply
By not switching to lion and waiting for ML you dodged a bullet.
[+] [-] inuhj|13 years ago|reply