I'm just wordering what happens when I run out of free RAM, What will Happen will my Inactive RAM become free RAM? I Don't know (lol)
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
What Happens When I have a Ton of Inactive RAM and No free RAM
- Thread starter AppleTecFan
- Start date
- Sort by reaction score
Inactive ram doesn't go into the free ram box, it's just remains available to any apps that need it. Inactive ram is basically ram that other programs got from free ram and remains in reserve to relaunch those apps. If no more ram is left in the "free" state new applications will use the inactive ram since it's not being used by the other programs that it was in reserve for. Hope that's clear enough.
Inactive ram doesn't go into the free ram box, it's just remains available to any apps that need it. Inactive ram is basically ram that other programs got from free ram and remains in reserve to relaunch those apps. If no more ram is left in the "free" state new applications will use the inactive ram since it's not being used by the other programs that it was in reserve for. Hope that's clear enough.
Thanks man I get it now
you're worry about an issue doesnt exist lol!
its merely a way of describing where the RAM is allocated, nothing to worry about.
its merely a way of describing where the RAM is allocated, nothing to worry about.
A page out:
basically it happens when you're RAM is all being used, so the OS starts to write the info to your hard disk. It's a lot slower than using the RAM, but for the most part with OS X, the software is smart enough that you wouldn't really notice unless it's paging like a mo' fo'.
thats what apple wants you to think. just because it says nothing has happened doesnt mean that nothing has actually been paged out. the fact that you have a VM size of 139GB tells me that page outs/ins are occuring, maybe not for the applications (which is probably what activity monitor only measures) but for OS etc.O rly?
I haven't paged out in forever...
when SOME RAM is being used
take for instance:
you have 500MB left of your 4GB total RAM. and you open up an application/large project that requires say 3GB of RAM. are you going to sit there for a good 20seconds and wait for the whole thing to be 'paged out' to your VM?? of course you arent! you will only have to wait for maybe 500MB or so, because a good portion of it is either already paged, or has been made inactive and is ready to be over-written.
well of course yes lol, memory usage from OS threads and all that duh. but i am uncertain if it monitors the lower level things.
It monitors the kernel, does it get any lower than that? Other than firmware, but that doesn't have much to do with memory management.
it does get lower then that in terms of CPU, but we arent after that.
talking strictly memory usage here, i highly doubt that every movement of RAM to VM and back is reported in the "page ins/outs" section.
thinking about it: the mere fact that you have VM means that some sort of pages have to occur! otherwise you wouldnt have any VM, simple as that!!
That's not quite right because everything in Mac OS X is 'virtual' memory, it just so happens that some of it is physical RAM. As a result, OS X does not treat RAM any different from the rest of the address space. For the most part, anything outside of the VM paging system doesn't even know that the RAM/Swap border exists (excluding kernel-space pages, aka: wired memory), all it knows it that it got a page it can read/write to. If userland applications were aware of the border you're looking at the potential for some really nasty bugs. Looking at the global VM size is also fairly useless as, by default, Mac OS X sets that size to be the total amount of free space on your boot drive.
There will always be some degree of page outs regardless of how much memory you have as OSX will attempt to keep everything it can (above a certain Free threshold) in either Active or Inactive memory. Since RAM is limited, no matter how much you have, eventually the amount of Free pages will dip below a threshold and the system will swap out some of the most unused Inactive pages. If you have a lot of RAM this will happen less often as much of the data in memory is shared code but at some point it will happen. If the system needs it back, it triggers a hard page fault (there are also soft page faults but these are just Inactive->Active transitions) and the swap page gets paged back in as Active. What you need to watch out for is excessive page out/in activity. Once in a while is fine, won't have a noticeable effect on your performance and is necessary for the system to run. If your HD is constantly grinding and your page out to page in ratio is really high then you have a performance killer. Trying to give you an excessive ratio is difficult, I usually aim for 0.35 or lower on my systems (multi-week/month average). For example, a single day with a 1.0 ratio is not a good reason to buy more RAM while a month of 0.75 probably is.
The main transitions are:
Free -> Active - Free memory above threshold, create a new page
Active -> Inactive - Page out, Page hasn't been touched in a while, may not be needed but keep it in memory
Inactive -> Active - Page in, Soft fault. Something needed an old page
Inactive -> Backing - Page out to swap, free memory has dropped below threshold value, Write page to HD and mark as Free. This is what is counted in your "Page Out" statistic.
Backing -> Free - Page in, Hard fault. Something needed an old page, find a free page and read in the needed page from the swapfile
One thing to note is that ANY page fault counts towards your page ins but only swap outs count toward your page out stat. It is entirely possible to have a system with a high number of page ins without any page outs.
The "Wired" section you see denotes memory that cannot be paged out. This is all kernel space memory structures; nothing in userland can exist here.
thanks for coming along i was hoping that somebody would explain it in great detail
life saver haha!
so you're saying that memory is one big chunk of space, including both physical and 'virtual', but how does it know where the physical stuff is? is the OS told what sectors of the memory are the part to write to via priority lists? e.g. from hex value 0 to a million. or something, then the rest are for when the "priority" memory is full/not being used etc?
i have seen my swap file larger then my page outs, is that even possible?
life saver haha!
i was not aware of that. windows handles it the conventional way? or does it also handle it in this manner?
so you're saying that memory is one big chunk of space, including both physical and 'virtual', but how does it know where the physical stuff is? is the OS told what sectors of the memory are the part to write to via priority lists? e.g. from hex value 0 to a million. or something, then the rest are for when the "priority" memory is full/not being used etc?
i knew i was right with the "always page outs" arguements, somebody told me long ago. i just never had enough in depth knowledge to say why i was correct haha. thankyou
well that is to be expected as the OS does this to make way for other applications/processes, or to "put aside" the things that are being used the least.
like mine
thanks! i have always wondered what the actual amount is. off a fresh restart i will find that i constantly get 1GB+ pageouts per day, swap memory hovers around 3GB (RAM is maxed on my poor MBP).
care to describe what a 'page' is? is it a "packet" of memory? what size are these pages?
i have more page outs then ins
i have seen my swap file larger then my page outs, is that even possible?yup i knew that much haha
Thanks for your description. I have some facts to add.
I would describe Inactive memory as unused memory but the OS knows the contents of every page. Free memory is unused memory with unknown contents.
If I start an application, its code will be paged in from the executable file as I execute it. When I stop the application the memory pages that held the app is no longer used, but the OS still knows the contents. So it is kept as inactive memory. If I were to start the app again, it would be (mostly) in memory already and the would be no need to read it from file again.
The hardware has a "dirty bit" for every RAM page that is set whenever a program writes to it. So the OS knows when it must do a page out before reusing a page. If the page hasn't been written to since it was swapped in, it can be reused without a swap out.
If another application needs memory, the pages in the Inactive list is ready for reuse. Note that if such a page contains code from an application that isn't running (for example), then the page can be reused directly without a page out. In this case the page in the Inactive list is as free and as readily usable as a page in the Free list.
yup
what is your understanding of it?
(im really into learning if nobody noticed haha)
Ok, here is another thing to learn
To write a file, a normal program opens the files and issues a number of "write file" calls to the OS (through whatever framework the program uses).
An alternative way is to map the file into memory (mmap). The file can then be read just by accessing the memory, as if it had been variables in the program. Similarly, you can update the file just by altering the same memory. Then there are calls to flush those changes to disk (msync). When you are done with the file you unmap it (munmap) and the pages will become inactive or free.
If you flush the pages (msync) the OS will do page outs. This will happen even if you have oceans of free RAM, because you told the OS to do it.
So if you are running a program that updates files in the manner I described, you cannot look at the "page out" counter to determine if you are "running low on RAM".
What's a page? It is just a contiguous block of memory. How much depends on the hardware architecture (and some architecture allows multiple page sizes). 4096 bytes is a common page size.
To write a file, a normal program opens the files and issues a number of "write file" calls to the OS (through whatever framework the program uses).
An alternative way is to map the file into memory (mmap). The file can then be read just by accessing the memory, as if it had been variables in the program. Similarly, you can update the file just by altering the same memory. Then there are calls to flush those changes to disk (msync). When you are done with the file you unmap it (munmap) and the pages will become inactive or free.
If you flush the pages (msync) the OS will do page outs. This will happen even if you have oceans of free RAM, because you told the OS to do it.
So if you are running a program that updates files in the manner I described, you cannot look at the "page out" counter to determine if you are "running low on RAM".
What's a page? It is just a contiguous block of memory. How much depends on the hardware architecture (and some architecture allows multiple page sizes). 4096 bytes is a common page size.
*takes in*Ok, here is another thing to learn
To write a file, a normal program opens the files and issues a number of "write file" calls to the OS (through whatever framework the program uses).
An alternative way is to map the file into memory (mmap). The file can then be read just by accessing the memory, as if it had been variables in the program. Similarly, you can update the file just by altering the same memory. Then there are calls to flush those changes to disk (msync). When you are done with the file you unmap it (munmap) and the pages will become inactive or free.
interesting. i had not considered the multitudes of ways to read a file, i just assumed it was already put into RAM (thus why large music/video projects can take forever to load).
so, once the file has been read into memory; if you change the file is the msync called automatically, or periodically? (i guess automatically with an autosave feature, and periodically with no autosave?).
ahhhh now i see! i knew these things happened but i was unsure as to why. you just turned the mud into glass!
..because the page out information is not correct
horrah i understand.believe it or not i was actually going to suggest the size being 4KB. i had a feeling
i guess this cant really be altered from program to program - its more of an OS thing? smaller is better i guess for RAM anyway.also: is there a seperate memory log kept somewhere? how big is this log in proportion to the actual memory size? (somewhat like how a HDD keeps a database for the rest of the sectors). so many questions!!
thanks very much for your time