Is there a way to determine which process(es) are contributing to Inactive Memory? I understand that it is not bad to have a significant amount of Inactive Memory.
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.
Analyzing Inactive Memory
- Thread starter mmccaskill
- Start date
- Sort by reaction score
It's memory that was used by an app but is no longer needed (for now). I don't know of an app to tell you what has been contributing to it, but I guess you just need to think back to what apps may have recently been using a bit of RAM but are currently fine with less.
The thing is I close all apps except Finder and inactive stays high. One would think eventually that would come down. It is ok though. I use iFreeMem.
That's the whole point. You can close the apps and yet their RAM contents remain in "inactive." If you reopen the app, you've already got data in RAM to get you going. It's not going to come down until you reboot (or is converted into "used" RAM). Or you can use something like iFreeMem to force the inactive RAM to free up.
Inactive Memory, in effect, is free memory. It's inactive because no process is actively using it. As soon as something comes along that needs the RAM, it's going to pull what it can out of the Inactive pool.
Consider your "Free" memory to be "Free" + "Inactive".
Consider your "Free" memory to be "Free" + "Inactive".
I understand the concept. But it gets to the point when I start swapping all because inactive contains portions of programs that I may use again. But in reality I know I'm not going to use them for a while so why keep that content in RAM and start swapping.
Ha-HA!
iFreeMem.
Looks like someone made a little poo-poo at the bottom of his DMG, because I can see the background file.
Before even opening the program I'm already not impressed. At all.
At what price does it work? What is it doing behind the scenes? Can I trust my box to a developer who doesn't read Apple's standard programming practices?
Would you hire someone for a sales position that looks like he just rolled out of bed, and didn't shower before his interview?
Dont worry about inactive memory.. It's not being used at all
http://docs.info.apple.com/article.html?artnum=107918
Other unix have the same "feature" and is one of the most common questions around. Just search "free memory linux" and you'll see that it's asked a lot.
Inactive memory shouldn't make your machine any slower, but should make it faster when you reopen an application and/or do some repetitive task.
If you find that your computer is running slow, then maybe, there's something else that it's making it slow.
http://docs.info.apple.com/article.html?artnum=107918
Other unix have the same "feature" and is one of the most common questions around. Just search "free memory linux" and you'll see that it's asked a lot.
Inactive memory shouldn't make your machine any slower, but should make it faster when you reopen an application and/or do some repetitive task.
If you find that your computer is running slow, then maybe, there's something else that it's making it slow.
I don't think you should worry about that anyhow. The system and its virtual memory manager were built so you wouldn't have to interfere. Virtual memory is nothing like what you might be used to on older systems such as MacOS. A few tutorials in what it does and why might be good before you venture further.
That depends on the particular implementation. You're talking about page frames that aren't "dirty". How much across the board the VM system wants to take responsibility for is implementation independent. Yes, most systems will exhibit this tendency, but it's not a given. Again, worrying about how VM works is not something people should do.
It's totally equivalent to deleted files. The data's still there. Does that help you much the next time you want to save a file?
Again not to be recommended.
http://radsoft.net/resources/software/reviews/redux/
I should have an auto-responder bot for all the Inactive Memory / Free Memory threads.
"Don't worry. Be Happy. Let OSX do its thing."
"Don't worry. Be Happy. Let OSX do its thing."
The reason apps may be able to load faster subsequent times is their actual binary images on disk can constitute the start of their on disk virtual memory representation. Nothing's read into swap (or into RAM for that matter - that comes later automatically with page faults thrown by the CPU). Read-only sections aren't ever dirty; data sections are normally marked as "copy on write": they stay as their VM representation but they're not read-only so the first time the process wants to write to them they must be copied - to neutral grounds in the generic swap area (swapfile*). But the page tables used for the process can still be around and the mappings used for all the dependencies can still be around too. Launching an application should be nigh on instantaneous: it isn't the transformation from program to process that takes time - it's the resolution of external references and rebasing the dependencies into the process address space. But if it's already been done...
It's entirely a different matter if you're editing a humungoid file, save it, exit, and try to start the app to open it again.
It's entirely a different matter if you're editing a humungoid file, save it, exit, and try to start the app to open it again.
I strenuously disagree with that. And I challenge your ability to determine exactly what it does or if it in fact actually works. And I do this for I know for a fact as a systems engineer that it does not and cannot.
Must insert a "doh" here. If these memory programs were so bloody brilliant you'd think the engineers responsible for the VM manager in OS X would do something similar. And I can't put my finger on why, but I have this sneaking - but inexplicable - assumption that they just might possibly theoretically be better at dealing with these matters than I don't know who with two apps in the UK with some funky ideas about allocating all available RAM to grind the system to a halt only to free it again to make you happy. Something like having an elephant hitch a ride on your shoulders - when he gets off it feels so good.
And there's an old story about the guy who feels crowded in his one room cold water flat and asks his rabbi for advice.
"Buy a goat," says the rabbi.
"Buy a goat?"
"Buy a goat."
So the guy buys a goat. And he tethers the goat to a bed post. But he's got to climb over this goat all the time - from his bed to his pantry and so on. Even to get out the door or back in. Finally he can't stand it anymore and he goes back to the rabbi.
"Rabbi, this goat is impossible! It's always in the way! When I get up in the morning to make my breakfast I have to climb over him! When I want to go out the door I have to climb over him! When I want to watch TV he's standing in the way! Tell me, Rabbi: what do I do?"
"Sell the goat."
Good point. I am not sure that I can without looking at the source code. Then again I'm not sure anyone can determine exactly what OS X does behind the scenes, can we?
Eh?
Good point. I am not sure that I can without looking at the source code. Then again I'm not sure anyone can determine exactly what OS X does behind the scenes, can we?
For a lot of low level functions we can.
http://developer.apple.com/opensource/index.html
Not only that, but the behavior that mac is showing is also found on other unix systems as I already mentioned in my first posts.
There's absolutely nothing to fear about. It's intended for the operating system to create this "inactive memory." It's definitely not something like an application with a memory leak that is going to slow down the whole system..
Interestingly enough I haven't rebooted the MacBook in 3 1/2 days so I'd thought I'd share some stats:
Wired: 321 MB
Active: 712 MB
Inactive: 755 MB
Free: 257 MB
Swap: 512 MB
Page Ins: 352,398
Page Outs: 4,022
Wired: 321 MB
Active: 712 MB
Inactive: 755 MB
Free: 257 MB
Swap: 512 MB
Page Ins: 352,398
Page Outs: 4,022
