Fear of Swapfiles OR Manual Memory Management

[petey]

I have a fear of Swapfiles, and I'm trying to figure out if it's a paranoid fear or not.

My config is an iBook w 640MB RAM. Despite all the RAM, I find OS X generating additional Swapfiles after a few days of Uptime unless I keep a sharp eye on memory management. And sometimes I get additonal Swapfiles no matter how hard I try to avoid them.

I manage memory through a few techniques. One is frequently quitting and restarting certain RAM expanders like the Finder and Internet Explorer. Another is keeping an eye on free memory, and quitting apps when free RAM gets low. The last and worst solution is rebooting.

I have multiple rationales behind the fear of Swapfiles:
- There's an obvious performance hit in writing to disk.
- An iBook hard drive is damn slow compared to a 7200RPM desktop drive.
- Dealing with Swapfiles eats into a portable's battery life.
- I only have about 1GB free on my drive, so having bunches of swapfiles eats into my free drive space, and also makes me worried about excessive fragmentation.

Currently, despite my best efforts at memory management, here's my current rundown:

Uptime: 9 days
Pageouts: 87MB
Swapfiles: 2

PhysMem: 61.9M wired, 223M active, 316M inactive, 601M used, 39.0M free

So if I now decide to launch Photoshop without quitting any apps, I'm going to Pageout to disk, and perhaps create a third Swapfile.

QUESTIONS:

- Why on Earth would OS X decide to Pageout to disk at this point, when I'm sitting on over 300MB of inactive memory?

- Does anyone have any simple ideas on how to reclaim inactive memory, so Photoshop wouldn't Pageout? (There's another thread on how to do this by using the UNIX Fink find command, but I'm UNIX-phobic enough to not want to go to such lengths.)

- Any other management tips I'm missing? Or any flaws in my basic understanding?

- Am I insane to worry so much about the performance hits of Pageouts? In other words, should I give up manual memory management, keep all the apps I use running, let OS X Pageout as much as it wants, and just reboot every few days to reclaim the disk space?

[Phil St. Romain]

petey, you didn't tell us what version of OS X you're using. 10.1.4? I'm not sure that would make a difference, but being up to speed here might help.

I've got a pismo powerbook with 640 RAM and haven't had the memory management problem you're describing. Ditto for my iMac with 320. There's something wierd about what you're describing. Are you experiencing actual performance hits with this situation?

I've found IE to cause wierd things to happen with memory and even the stability of other apps, so I finally quit using it and everything seems to go better.

Finally, you do know, I've sure, that you can wipe your RAM without rebooting completely; just log out and then log back in.

[petey]

Phil,

- I'm running 10.1.4.

- Logging Out/In does not get rid of Swapfiles, AFAIK. And it seems a less viable solution for increasing free RAM than quitting running apps.

- I don't think I'm the only one who has issues with excessive Inactive memory. See the second half of the thread http://forums.macosxhints.com/showth...&threadid=2780

- From conversations with others, I don't think I'm the only one who generates multiple Swapfiles over time, no matter how much RAM is installed.

- Yes, I do see a performance hit when I Pageout. But my perceptions could be wrong.

[mervTormel]

pageouts are very expensive. 87MB of pageouts is painful. multiple swapfiles is an indicator of severe memory shortage.

i'd say the number one thing you can do is to buy as much memory as you can.

but, when you are memory starved, show us your top 15 real RAM eaters:

% ps waxum | head -15
USER     PID %CPU %MEM      VSZ    RSS  TT  STAT      TIME
   COMMAND
merv      69   0.6  2.4    66988  37148  ??  Ss     1:08.25 
   /System/Library/CoreServices/WindowServer
merv     426   0.0  1.3   110812  21064  ??  S      0:10.56 
   /Volumes/chunder/xapps/Microsoft Office X/Microsoft Entourage
merv     427   0.2  1.2   102560  18968  ??  S      0:54.40 
   /Applications/Internet Explorer.app/Contents/MacOS/Internet Explorer
merv     347   0.0  1.1   100912  17500  ??  S      0:06.86 
   /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder
 
...

[petey]

Merv,

To refer to my system at the time of my original post:

PhysMem: 61.9M wired, 223M active, 316M inactive, 601M used, 39.0M free

So if I added up the RAM used by all of my processes, it would only be 223MB. It seems to me that inactive memory is the problem.

If I now launch Photoshop, shouldn't a smart VM system find that needed memory from the inactive pages, instead of paging out to disk?

[mervTormel]

Quote: ...shouldn't a smart VM system find that needed memory from the inactive pages, instead of paging out to disk?

well, not if any of those inactive pages haven't expired yet.

granted, you have a large pool of inactive pages and it would seem prudent for VM to flush some to make room for PS, but it's complicated and i don't know too very much about it; there are a lot of 'time' based algorithms in VM, so, some 'times' you may have more stale pages that would flush than remain inactive.

you might try launching PS early and leave it running rather than try to pound it in later.

i'd still like to see your top 15 RAM consumers.

[petey]

sorry for the mess, but i can't figure out how to use vbCode to get monospaced text.

[localhost:~] petey% ps waxum | head -15
USER PID %CPU %MEM VSZ RSS TT STAT TIME COMMAND
petey 68 0.9 5.8 60276 37924 ?? Ss 390:47.15 /System/Library/CoreServices/WindowServer
petey 4838 0.1 5.2 102084 34328 ?? S 20:37.41 /Applications/Internet/Internet Explorer.app/Contents/MacOS/Internet E
petey 3264 0.0 4.9 98832 32424 ?? S 11:50.73 /Applications/Utilities More/Quickeys/QuicKeys.app/Contents/MacOS/Quic
petey 4881 0.0 4.1 116204 26972 ?? S 8:31.52 /Applications/Microsoft Office X/Microsoft Word /Applications/Microsof
petey 373 0.0 3.4 78608 22040 ?? S 1:49.82 /System/Library/CoreServices/System Events.app/Contents/MacOS/System E
petey 4813 0.0 2.7 77228 17976 ?? S 1:13.89 /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder -psn_0_1
petey 4594 0.0 2.2 72992 14208 ?? S 1:13.89 /Applications/Writing/DEVONthink/DEVONthink.app/Contents/MacOS/DEVONth
petey 3230 0.0 1.6 91516 10604 ?? S 6:01.96 /Applications/Internet/Eudora 5.1/Eudora.app/Contents/MacOS/Eudora /Ap
petey 3133 0.0 1.2 65060 8008 ?? S 5:32.17 /Applications/Utilities More/LaunchBar.app/Contents/MacOS/LaunchBar -p
petey 277 0.0 1.2 52996 7792 ?? Ss 1:28.75 /System/Library/CoreServices/loginwindow.app/loginwindow console
petey 4837 0.0 1.2 65992 7568 ?? S 0:11.10 /Users/petey/Library/PreferencePanes/MaxMenus.prefPane/Contents/Res
petey 3249 0.0 1.0 66364 6640 ?? S 10:50.81 /System/Library/CoreServices/SystemUIServer.app/Contents/MacOS/SystemU
petey 4989 10.3 0.8 60912 5120 ?? S 0:02.22 /Applications/Utilities/Terminal.app/Contents/MacOS/Terminal -psn_0_10
petey 4932 0.0 0.7 56512 4744 ?? S 0:04.73 /System/Library/CoreServices/Dock.app/Contents/MacOS/Dock -psn_0_10603

[ashevin]

1) Inactive memory is memory that is claimed by a running application, but has not been accessed in some amount of time. I don't know who decided how much time that is, probably the vm system. Inactive memory is the one of first "types" of memory to be swapped out when more physical memory is required (like when starting another App). To answer your first question then, it is precisely because it is inactive that it is swapped out. Inactive doesn't mean free.

2) The only way to get rid of inactive memory is to quit the applications that have claimed it. From the sound of it, this is precisely what you are doing.

The purpose of the VM system is to manage memory for applications as well as the kernel. Memory is used by the kernel for essentially 2 things: One is data structures that it needs to do its job. Things like the list of running applications and a map of all the memory used by each application. The other kernel use of memory is to buffer data that needs to be written to disk, or that has been read from disk. This is to prevent disk access for as long as possible during normal operation.

For Applications, the VM is responsible for allocating pieces of the virtual memory space to applications, as requested. When the total virtual memory requested exceeds the amount of physical memory, a swapfile is created. Each time an application accesses memory within its allocated space, that memory has to be in physical ram. If it's not, it has to be in the swapfile. The VM checks to see if there is a free page of memory available to swap in the required page. If there is, it is swapped in. This is the pageins number that top shows. If there is not already a free page, one has to be chosen and swapped out first. This is the pageouts number in top.

The question is, how does the VM decide which page to swapout? The answer is that it scans all the allocated pages based on what the page is allocated for. If it used for the kernel disk buffers, it is written out to disk (if dirty) and reclaimed for the App that needs it. If there are no buffer pages, the Inactive list is scanned, and the oldest non-modified page is reclaimed. If there are no inactive pages, the VM resorts to kicking out some active program's memory, and you start to see heavy swapping as different applications become active.

Within that explanation is the reason that the "find" trick works. What that tip says is to use the unix "find" command to list all the files on your harddrive. What happens is that the kernel will start kicking everyone else out of memory to make room for all the directory information that find requires. When the find command finishes, all that data is still there but it's in the disk buffers. Because find didn't change any of this memory, the kernel can reclaim it as necessary without doing any disk access. Thus you clean out all the inactive pages from memory and replace them with disk buffers that don't have to touch the disk. It should be noted that all the inactive pages (and possibly a large number of active pages) will have been written to disk (swapped), and will probably be swapped in at some point.

I hope this nice long post helps to explain why you see what you do with respect to memory usage.

- Avi

P.S. The explanation may not have all details correct, as I am basing it on my knowledge of VM systems in general, and not on the Mach VM in particular.

[petey]

I issued a 'ps aux' command, got a list of processes, then added up the cumulative RSIZE's. I got a total of 277MB.

Then I issued a 'top' command, and got the following report:

PhysMem: 69.0M wired, 123M active, 407M inactive, 599M used, 41.0M free

---

My question:

- What is the relationship between the 277MB number, and the 'top' report. It doesn't seem to make any sense to me.

- Why am I using 599MB of memory when my processes are only using 277MB?

[ashevin]

I'd have to check OS X's ps manpage, but I would guess that the RSIZE for each process includes shared library code. The number from top does not count the shared library code more than once, thus the lower, more accurate number.

Again, the Inactive pages are simply those that have not been dirtied (written to) since the last time they were written to disk. Or pages that have not been accessed in some time. I have to check into Darwin a bit more to know what top means by Active/Inactive. A number of them may be the disk buffering that I referred to earlier. That is why they are not considered part of any process.

I will take the time to examine this in more detail, but I bet I'm pretty close. Suffice it to say, there is no reason to believe you're seeing a memory leak or any other sign of mis-management. You're just seeing memory counted in different ways depending on the purpose of allocation and by who's reporting the numbers.

- Avi

[ashevin]

Me again.

Here is a document on Apple's developer site that should explain all the things you've been asking about.

Virtual Memory on Mac OS X

It shows I had several details wrong, but in essense, I think I was correct.

- Avi

[petey]

hey avi,

thanks for the link & explanation. it helps get the picture a bit less foggy.

--------------------

i guess the real world, end user hypothetical i'm trying to solve is this:

say my system looks like this -
PhysMem: 69.0M wired, 123M active, 407M inactive, 599M used, 41.0M free

now i want to launch photoshop, which is going to end up having an RSIZE of 100MB. do i...

a) quit microsoft word & internet explorer (i use both frequently), launch and do my work in photoshop (which i use less frequently), quit photoshop, and then relaunch word & explorer.

b) launch photoshop, let the VM system Pageout to disk, do my work in photoshop, and then quit photoshop.

c) launch photoshop, let the VM system Pageout to disk, do my work in photoshop, but then don't quit photoshop, even though i may not use it again for a couple of days.

unless i pursue option a, i'm going to end up with multiple swapfiles after a week.

any suggestions on which strategy to pursue?

[mervTormel]

avi, thanks for the sterling posts. there's got to be some 'optimization' in the mach VM engine because i experience very few pageouts (1.5GB RAM) for huge amounts of processing. fink update-all ran for hours today, 0 pageouts. but fink's find flushes inactive pages real fast, with 0 pageouts. it's all about thresholds and how close you are to them and what kind of processing you do. i think petey is a 'cusp' customer. i need to read that apple doc a few more times...

now, for some levity...

Quote: Originally posted by petey I issued a 'ps aux' command, got a list of processes, then added up the cumulative RSIZE's. I got a total of 277MB...

petey, did you don your accountant's green visor for that calculator session?

here's a handy awk command for summing columns of numbers:

% ps aux | awk '{sum += $6} END{print sum}'

below is a script to let you do this:

% ps aux | zca 6    # example script usage

------------------

#! /bin/sh

#  zca - column adder - add up all numbers in column N
#  of file(s) or stdin
#  Usage: zca columnNumber [files]

# get column, leave file(s) in ${1+"$@"} (work around sh issue)

case "$1" in

  [1-9]*) colnum="$1" ; shift ;;

  *) echo "Usage: `basename $0` colnum [files]" 1>&2 ; exit 1

esac

awk "{sum += \$$colnum} END{print sum}" ${1+"$@"}

exit 0

[petey]

merv,

ever since i soldered a USB port onto my old abacus, calculations have been a breeze.

i'm sure i'll have a decent elementary knowledge of UNIX in 3 years or so.

----------------------

It's interesting to know you have few pageouts at 1.5GB. (I'm assuming you reboot infrequently.) I figured the kernel would fill all available memory, no matter how big. In other words, I thought it wasn't an issue of my 640MB. Too bad my iBook is maxed out.

----------------------

Want to take a guess at the hypothetical in the above post?

[ashevin]

I'll take a stab at answering both your hypothetical question and at explaining what Merv sees with find vs fink update-all.

First the hypothetical:

I don't have an insider's view on how PS does file access, but given that Adobe tries to optimize for max performance, I would guess they use memory-mapped files. If this is the case, there is no reason not to leave PS running.

Here's why: Data from disk that is known by the VM to be readonly is never placed in a swapfile. This includes code read from program files, and it includes data read from memory-mapped files if that data has not be changed by the program. As long as you save the images that you are working with in PS, they should not be swapped to a swapfile.

If I am wrong about how PS reads images, you can simply close all images when done with that session, and achieve the same effect. The only data that will be swapped out will be variables and data structures that PS needs as it runs. This should be very minimal if you have no images open.

One thing that I am seeing with my own tiBook is that I seem to have an unused swapfile still on disk. I don't know if the pager ever gets rid of extra swapfiles with a reboot to clear them away. (The startup rc scripts delete everything in /var/vm upon boot.) If Apple makes it available as part of Darwin, I will try to get the source and check that out.

[EDIT]
I found this quote in an ADC document:
"When the total fullness of the paging file pool reaches a high water mark, the default pager asks the dynamic pager to allocate a new store file. When the pool drops below its low water mark, the VM system selects a pager file, moves its contents into other pager files, and deletes it from disk."
[/EDIT]


Now on to explain what Merv sees...

First find: when you run find, there are 2 things going on... One is that the dataset that find is working with grows to be fairly large. As the active dataset increases, more pages are stolen from the Free list to accomodate. As the threshold on Free pages is reached, pages are stolen from the Inactive list. At the same time, find is causing the kernel to read in all the metadata from the filesystem, which is stored in the Wired pages as it is cached. This action also puts pressure on the Free pages, which in turn steals more from the Inactive pages. At the end, when find finishes, it relinquishes all it's Active pages directly to the Free list, and, voila!, no more Inactive pages

When you run fink update-all, you are actually seeing several (of the same) programs run over and over again with relatively small datasets. Once enough memory is stolen to, say compile one source code file, that same memory is used by each subsequent step in the process. A little bit more on occasion, but never enough to use even close to all of physical memory. Compiling code is much more cpu intensive than memory instensive. The process does benefit from more memory when the dependencies are complex enough that the same files are referenced multiple times. This is very unlikely to be the case unless you routinely compile XDarwin, or Darwin itself very often.

- Avi

[mervTormel]

i discovered some more inactive page flushing behavior.

i've been scripting my ditto backups. now, ditto is going to put a lot of pages in the inactive pool. i can visually see it rise using 'memory monitor'.

at the end of my ditto, i du -cs the source and target, and watch the inactive pages plummet. 'roller coaster, i love...'

note: this is fink's du, haven't tried the vanilla.

[petey]

so, the consensus is...

never quit apps. don't worry about manual memory management. let the swapfiles come as they may.

sound sensible?

[ashevin]

I wouldn't say never As that first article I pointed to states, each process uses up some Wired memory, which is memory that is not swappable. It would be safe to say that anything you will be using within a short while (from a human perspective) can just be left running. I leave each human to define "short while" for himself

Personally, I hate having unused apps to cycle through with cmd-tab, so I quit things as soon as I think I'm done with them.

- Avi