I recently installed an SDD into my MacPro, and was paying attention to the storage used, both to be comfortable the SSD size was going to be enough, and also that the TM backup hard drive wouldn't fill too fast. This morning I noticed the /private/var/vm folder had swapfiles totaling 64GB. My question would be how to reduce this and to understand why it happens. The SSD size is only 128GB, and was running 60GB or so. This runaway issue was about to create a 'no room' problem, although I suppose that would have forced a reboot anyway.

I read What are the “sleepimage” and “swapfile” documents? and it warned not to delete these files. I searched some more, and found that a reboot wiped it all out. After the boot, there’s one swapfile of 67MB, versus the 64 files each a full GB.

I never saw this before. I understand a reboot is the answer, but is there anything to do to prevent it occurring? I’d at least like to understand what process or app set this in motion.

I am running 10.6.8 Snow Leopard

  • 1
    What version of OS X? see many questions here on virtual memory - when you give more info I suspect that will be enough to point you to the correct question
    – mmmmmm
    Feb 2 '15 at 16:54

Probably one (or more) process on your system was running wild.

Use your Mac as usual. From time to time check the folder /var/vm and if you run across a lot of swap files open Terminal.app and enter:

ps xa | awk '{print $1}' | xargs -n 1 sudo vmmap | grep -A3 'Summary' > /Users/YourUserName/Desktop/vmmap_summary.txt

Depending on the number of running processes this will take about 30-60 seconds. Your account has to be able to run sudo (=usually an admin account).

This creates a text file called vmmap_summary.txt on your desktop which contains some memory and swap information of all running processes sorted by PID. Some will fail because their process id is already gone.

Example (truncated to the first four PIDs):

==== Summary for process 1
ReadOnly portion of Libraries: Total=51.8M resident=12.9M(25%) swapped_out_or_unallocated=38.9M(75%)
Writable regions: Total=92.9M written=808K(1%) resident=2112K(2%) swapped_out=0K(0%) unallocated=90.8M(98%)

==== Summary for process 21  
ReadOnly portion of Libraries: Total=77.0M resident=30.9M(40%) swapped_out_or_unallocated=46.1M(60%)  
Writable regions: Total=88.5M written=1116K(1%) resident=5144K(6%) swapped_out=0K(0%) unallocated=83.4M(94%)

==== Summary for process 22
ReadOnly portion of Libraries: Total=150.1M resident=60.1M(40%) swapped_out_or_unallocated=90.0M(60%)
Writable regions: Total=93.2M written=1460K(2%) resident=5440K(6%) swapped_out=0K(0%) unallocated=87.8M(94%)

==== Summary for process 23
ReadOnly portion of Libraries: Total=77.2M resident=31.3M(41%) swapped_out_or_unallocated=45.9M(59%)
Writable regions: Total=96.9M written=1412K(1%) resident=2036K(2%) swapped_out=0K(0%) unallocated=94.9M(98%)

Check for any bad behaving process (swapped_out>>>0k).

To get the process name of a misbehaving PID and some more information enter:

ps aux | awk '$2 == PID  { print $0 }'

Example output for a process with the ID 21 — ps aux | awk '$2 == 21 { print $0 }' — would be:

root              21   0,0  0,0  2507740   6552   ??  Ss   10:03am   0:01.48 /usr/libexec/kextd

Now hunt down what may be wrong with the app or daemon.

  • Over 24hrs and the one swapfile hasn't grown at all. I'll use this advice if/when it does. Feb 3 '15 at 17:05

The swapfile items you should not touch as they are part of the core structure of the Mac OS X system; similar swapfiles exist on other Unix/Linux systems. But the sleepimage file can be safely deleted as long as you know what it does and what functionality you will lose if you remove/disable it.

Basically, in “old school” sleep mode, if you had applications open and then put your Mac to sleep and then the Mac lost power, it would have been as if you ripped the power cord out of the wall. Meaning the state of all of the apps would be nullified and your work would disappear into the digital ether.

But the new type of sleep mode (aka: “hibernate mode”) uses sleepimage to add a safety net if you need it. Meaning, when you go to sleep on a Mac that supports it (depends your system; more details in this answer), the system will save a snapshot of your system (aka: what is in RAM) to the hard disk in a sleepimage file. That way if your Mac loses power, your work application state and related work is saved to disk. So when the machine powers up again, guess what? The sleepimage is loaded into RAM and you are back to normal again.

Sounds cool, but it’s only really useful for portable Macs like the MacBook, MacBook Pro, MacBook Air, etc… For someone like me—who works on a desktop-based Mac Mini—it’s fairly useless since I am plugged into AC power all the time. So when I did a recent system rebuild and saw an 8GB sleepimage file taking up valuable space, I got rid of it. And here is how you can do that as well; first check to see what hibernatemode is set to on your system:

pmset -g | grep hibernatemode

One of the three option settings you should see are:

  • 0: Old school sleep mode with no safety net. Best for desktops.
  • 3: Hibernate sleep mode with the sleepimage safety net. Will keep RAM powered while sleeping for fast wake. Best for portables.
  • 25: Hibernate sleep mode with the sleepimage safety net. Powers down RAM during sleep and will always wake up by loading sleepimage. Best for portables and saves power/battery life by not sending power to RAM chips.

Now knowing that if you want to disable it, you now run this command to set hibernatemode to 0:

sudo pmset -a hibernatemode 0

With that done, ditch the sleepimage file:

sudo rm /private/var/vm/sleepimage

And that frees the space. But there is still a risk of it being recreated in the future; during a system update for example. So this is how you can ensure the sleepimage file is never recreated. First create a zero length placeholder for the sleepimage file:

sudo touch /private/var/vm/sleepimage

Now change set the “immutable” flag on the file to ensure it never gets written to:

sudo chflags schg /private/var/vm/sleepimage

With that done, sleepimage should be removed, space reclaimed and the risk of sleepimage being recreated is eliminated. But like I said, if you are using a portable Mac and rely on sleep mode, disabling this is not advised.


Swap files are a fact of Unix life. The only way to reduce them is to add more RAM to your system, so that they are not needed as often.

Once a swap file is created, the only way to reclaim that space is by rebooting.

(There are webpages out there which will tell you how to disable swap files. I strongly recommend that you do not do this, as Mac OS X expects them to be there.)

  • Please edit your question. Depending on properly set high- and low-water marks take it for granted that swap files are deleted without rebooting in a normally working system.
    – klanomath
    Feb 2 '15 at 17:58
  • Understood. I've been running the OS on the SSD for 3 months, this is the first time I've seen this issue, and 64GB of these swap files seemed strange, not quite a natural thing to expect. Feb 2 '15 at 18:51
  • Did you mean "edit my answer"? I didn't ask a question. I looked around for information about setting low and high water marks on OS X and didn't find anything. Perhaps you'd like to contribute an answer of your own rather than downvoting others?
    – TJ Luoma
    Feb 4 '15 at 4:16
  • @TJLuoma Sorry i meant answer (instead of question) but realized it too late. BTW I didn't downvote your answer.
    – klanomath
    Feb 4 '15 at 8:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .