Analyzing Inactive Memory

Discussion in 'macOS' started by mmccaskill, May 18, 2007.

  1. mmccaskill macrumors 6502

    Joined:
    Jan 3, 2007
    #1
    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.
     
  2. mad jew Moderator emeritus

    mad jew

    Joined:
    Apr 3, 2004
    Location:
    Adelaide, Australia
    #2
    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.
     
  3. mmccaskill thread starter macrumors 6502

    Joined:
    Jan 3, 2007
    #3
    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.
     
  4. WildCowboy Administrator/Editor

    WildCowboy

    Staff Member

    Joined:
    Jan 20, 2005
    #4
    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.
     
  5. epochblue macrumors 68000

    epochblue

    Joined:
    Aug 12, 2005
    Location:
    Nashville, TN
    #5
    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".
     
  6. mmccaskill thread starter macrumors 6502

    Joined:
    Jan 3, 2007
    #6
    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.
     
  7. SC68Cal macrumors 68000

    Joined:
    Feb 23, 2006
    #7
    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.
     
  8. mmccaskill thread starter macrumors 6502

    Joined:
    Jan 3, 2007
    #8
    Sounds reasonable. Judge the program by the DMG before using it. Who cares? Does it work? Yes.
     
  9. SC68Cal macrumors 68000

    Joined:
    Feb 23, 2006
    #9
    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?
     
  10. Mr.Texor macrumors regular

    Joined:
    Apr 20, 2007
    #10
    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.
     
  11. Fairly macrumors regular

    Joined:
    Sep 24, 2006
    Location:
    Cambridge UK
    #11
    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/
     
  12. SC68Cal macrumors 68000

    Joined:
    Feb 23, 2006
    #12
    Memory is one of the fundamental tasks that the OS manages. Why you would buy this app is beyond me. You think some schmuck on the internet with Xcode knows more than the OS developers?
     
  13. CanadaRAM macrumors G5

    CanadaRAM

    Joined:
    Oct 11, 2004
    Location:
    On the Left Coast - Victoria BC Canada
    #13
    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."
     
  14. Fairly macrumors regular

    Joined:
    Sep 24, 2006
    Location:
    Cambridge UK
    #14
    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.
     
  15. Fairly macrumors regular

    Joined:
    Sep 24, 2006
    Location:
    Cambridge UK
    #15
    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.
     
  16. Fairly macrumors regular

    Joined:
    Sep 24, 2006
    Location:
    Cambridge UK
    #16
    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. :D

    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."
     
  17. mmccaskill thread starter macrumors 6502

    Joined:
    Jan 3, 2007
    #17
    My humble apologies. A very good point indeed. Thanks for pointing that out.
     
  18. mmccaskill thread starter macrumors 6502

    Joined:
    Jan 3, 2007
    #18
    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? :eek:

    Eh?
     
  19. Mr.Texor macrumors regular

    Joined:
    Apr 20, 2007
    #19
    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..
     
  20. mmccaskill thread starter macrumors 6502

    Joined:
    Jan 3, 2007
    #20
    Ah very good. It seems we can verify this. Thanks.
     
  21. mmccaskill thread starter macrumors 6502

    Joined:
    Jan 3, 2007
    #21
    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
     
  22. itsallinurhead macrumors 6502

    itsallinurhead

    Joined:
    Apr 23, 2007
    Location:
    Southern California
    #22
    Tell us how you really feel. :p
     

Share This Page