Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

inactive RAM = 5GB?

F

firstyearprof

macrumors member
Original poster
Apr 16, 2007
52
0
Hi,

I have a 2008 Mac Pro 3.0, 18GB RAM. From the "top" command in terminal, I'm showing 5GB of inactive RAM. I've read that such RAM is apple's way of keeping RAM in reserve in case the same application needs it in the future, but that it will give that RAM to another application as needed (or something like that).

HOWEVER, yesterday I was using an application that got up to about 12GB RAM, *and then it started swapping to hard drive* (the pageouts went from 0 to 327000), all the while that 5GB inactive RAM just sat right where it was. :(

I had been expecting my application to be able to access this inactive RAM once it ran out of free RAM rather than swapping to hard drive. What gives? I can't believe that the Leopard OS is this inefficient with memory allocation, so I'm guessing I'm not understanding something. Any ideas?
 
im not sure but heres a good article from Apple that explains Mac OS X's memory management.

i think inactive RAM in only used if a new process requests it. so if your using the same RAM hungry app the inactive RAM wont be used.

BTW 18 GB! SWEEET! you should allocate some of it as a super fast scratch disk.
 
firstyearprof said:
Hi,

I have a 2008 Mac Pro 3.0, 18GB RAM. From the "top" command in terminal, I'm showing 5GB of inactive RAM. I've read that such RAM is apple's way of keeping RAM in reserve in case the same application needs it in the future, but that it will give that RAM to another application as needed (or something like that).

HOWEVER, yesterday I was using an application that got up to about 12GB RAM, *and then it started swapping to hard drive* (the pageouts went from 0 to 327000), all the while that 5GB inactive RAM just sat right where it was. :(

I had been expecting my application to be able to access this inactive RAM once it ran out of free RAM rather than swapping to hard drive. What gives? I can't believe that the Leopard OS is this inefficient with memory allocation, so I'm guessing I'm not understanding something. Any ideas?
Click to expand...

Which brand of RAM are you using ? (Hope not APPLE !!) And what are the temperature of each ? I noticed that on mine, DIMM 1 & 2 on the top riser are the hottest - at first I thought it was the RAM, but when I switch them to the bottom riser, the temp dropped and the replacement rose. I guess it is the position and/or being utilized more?

richthomas: how do set superfast scratch drive to use the extra RAM? I too have 18 GB and not fully utilizing them all.
 
To answer:

The application is R (open source statistics) 64 bit. It should be able to access a virtually unlimited amount of RAM.

I have OWC RAM. My temps were a major concern (getting up to 176F !!) until recently - after putting them through a day of big time work, they now never get above 155F. :confused:

Anyway - I think this is a leopard issue... to wit: WHY IS LEOPARD ALLOWING INACTIVE MEMORY TO SIT THERE WHEN AN APPLICATION NEEDS IT?
 
I get it now I think

Hi all,

I think I understand what's going on. It is explained here:
http://developer.apple.com/document...tual/ManagingMemory/Articles/AboutMemory.html

BEGIN QUOTE:

The active list contains pages that are currently mapped into memory and have been recently accessed.

The inactive list contains pages that are currently resident in physical memory but have not been accessed recently. These pages contain valid data but may be released from memory at any time.

The free list contains pages of physical memory that are not associated with any address space of VM object. These pages are available for immediate use by any process that needs them.

When the number of pages on the free list falls below a threshold (determined by the size of physical memory), the pager attempts to balance the queues. It does this by pulling pages from the inactive list. If a page has been accessed recently, it is reactivated and placed on the end of the active list. If an inactive page contains data that has not been written to the backing store recently, its contents must be paged out to disk before it can be placed on the free list. If an inactive page has not been modified and is not permanently resident (wired), it is stolen (any current virtual mappings to it are destroyed) and added to the free list. Once the free list size exceeds the target threshold, the pager rests.

END QUOTE


If I understand correctly, the page outs are not always a symptom of using virtual memory rather than RAM. Rather, when inactive memory is requested, it is given to the active application, but whatever is stored in inactive memory needs to be paged out to hard disk first - it is then given to the application.

So I guess that when my application requested more memory than was free, the OS first paged out the memory to the hard drive and then gave it to the application (it must have been a tiny amount given that I didn't notice the inactive memory decrease).

Does this make sense?
 
firstyearprof said:
If I understand correctly, the page outs are not always a symptom of using virtual memory rather than RAM. Rather, when inactive memory is requested, it is given to the active application, but whatever is stored in inactive memory needs to be paged out to hard disk first - it is then given to the application.

So I guess that when my application requested more memory than was free, the OS first paged out the memory to the hard drive and then gave it to the application (it must have been a tiny amount given that I didn't notice the inactive memory decrease).

Does this make sense?
Click to expand...

Yeah, I think you got it more or less. What is happening to the real
memory used by your application (Real Memory column in Activity
Monitor and RSIZE column from 'top')? Is it hitting a 12GB ceiling?
I'd expect your memory-intensive application to be given pages stolen
from other less active applications (i.e., pages that were marked as
inactive and subsequently moved to the free pool).
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back