On Nov 28, 2006, at 3:48 PM, Trevor Gilchrist wrote: > It's fascinating to see how much each > one influences memory consumption and most of the time the feedback > from the Activity > Viewer makes sense. But recently, I've been watching the dark blue > "inactive" memory > segment — which I believe to be the cached 'waiting to be re-used' > memory — just fill and > fill until it's, well, full. At that point I get erratic behaviour > (clicks and stutters etc.) in Logic > and the only thing that I can find to clear back to proper > functionality is a restart. Logic > doesn't crash, per se, but it certainly seems to be straining. My > "active" memory segment > rarely gets up much beyond a few hundred MB. > > Is there enough detail in this description to get some advice from > someone with a bigger > brain than mine, 'cos I'm not sure what's going on. Is the > 'Inactive' memory segment where > the machine hangs on to samples on the off-chance I might need > them? If so, can I clear it > — like the 'purge' commands one finds in Adobe programs? Inactive memory is memory that hasn't been accessed in awhile, so it is eligible to be swapped to disk. The most likely scenario is that your rig is reading large sample libraries into RAM and then not using most of it. If your free memory goes down to close to zero (10-20MB or less) you simply don't have enough RAM. The stuttering starts when the o/s has to start swapping to and from disk. The giveaway is to look at the "page out" count (the second number on the page in/out line.) If it is nonzero, you have been swapping, and if it is going up, you're swapping now. (Conversely, if the page out count is zero and stays there, buying more RAM will *not* make your system run faster.) Additionally, the VM system will leave the executable code of applications that have exited as inactive memory, so that if you relaunch the application it will load faster the second time (since at least parts of it are already in RAM.) Since this memory is marked read-only, it will never get swapped out if the system needs more RAM (it will just get freed, and it will load from the application file again as needed.) This isn't optimal for your purposes, since the system may end up swapping other stuff unnecessarily while leaving the executable code pages in RAM, so if your memory is really tight it isn't a bad idea to reboot the system before starting your work (and not running anything other than the applications you require.) There is no manual method of flushing this memory (and it wouldn't help you in any case, since it will just write all those samples out to disk and make things run even more slowly.) To make a long story short, you need to get more RAM if you're running out... --Dave