Releasing swap space

All we need is an easy explanation of the problem, so here it is.

At times the kernel seems to be intent on keeping e.g. firefox in swap, even though there is enough physical memory available and I’m using firefox:

[email protected]:~> free -m
             total       used       free     shared    buffers     cached
Mem:          3009       1904       1104          0        109        679
-/+ buffers/cache:       1116       1892
Swap:         4102        885       3216

Is there a command to instruct the kernel to drop swap space and use the available free memory?

Update: although in the short term I’ve used swapon/swapoff, I now set

sudo sysctl vm.swappiness=30

as suggested in another response, and get very good results.

How to solve :

I know you bored from this bug, So we are here to help you! Take a deep breath and look at the explanation of your problem. We have many solutions to this problem, But we recommend you to use the first method because it is tested & true method that will 100% work for you.

Method 1

You could do a swapoff — will need root privileges,
but, I guess that is not a problem for you.

Method 2

You could do what nik suggested and use swapoff. However, there is another, more elegant way to tweak “swappiness”, or how aggressively the kernel swaps programs out to disk in systems running the 2.6 kernels.

There have been heated debates on the linux kernel mailing lists about the policy the kernel should follow regarding swapping behaviour. The upshot is that we now have a patch in 2.6 kernels that lets us tweak this behaviour to a large extent.

Note that you need root privileges to do this, as you would to run the swapoff/swapon commands.

The current value of “swappiness” can be inspected in the /proc/sys/vm/swappiness file, or by running this sysctl command:

sudo sysctl vm.swappiness

The “swappiness” values can range from 0 (no swapping) to 100 (swap to disk as much as possible). Ubuntu ships with the default swappiness set to 60.

To change this for a session, call sysctl again and pass it a swappiness value to use:

sudo sysctl vm.swappiness=30

Besides free, you can of course monitor the effects of doing this via the excellent htop or iotop utilities.

If you like what you see, and want to retain this value across reboots, just place “vm.swappiness=30” in the /etc/sysctl.conf file.

$ sudo sysctl vm.swappiness
vm.swappiness = 30
$ sudo sysctl vm.swappiness=40
vm.swappiness = 40
$ sudo sysctl vm.swappiness
vm.swappiness = 40
$ sudo tail /etc/sysctl.conf 
#net.ipv4.conf.all.accept_source_route = 0
#net.ipv6.conf.all.accept_source_route = 0
# Log Martian Packets
#net.ipv4.conf.all.log_martians = 1
# The contents of /proc/<pid>/maps and smaps files are only visible to 
# readers that are allowed to ptrace() the process
# kernel.maps_protect = 1

You can play with different values till you find one that entails an acceptable level of swapping on your machine.

Method 3

Remember that the stuff in swap was put there at a busier time than now.

You might well find that the data is also in RAM – having been loaded back for use but not wiped from swap. The kernel does this to save time in the next busy period – if the data is already copied there it can just release the RAM it is using instead of having to do disk writes first. So unless you know the machine is not going to need to swap again in the near future, forcing the freeing of swap space may achieve nothing except to slow things down a little more next time swapping is needed.

This is managed on a delete-on-write basis, so if the copy in RAM is updated the blocks in swap will be released.

If the swap space is needed for something else, which it won’t be at the moment as you have plenty free, it will of course be released for that use.

You can’t see how much data is in this state (of being both in disk-based pages in swap areas, and in RAM) in the output from free. You can see it via the /proc special filesystem though. Look at the output of cat /proc/meminfo for the SwapCached count.

Another two reasons for there to be swap in use when there is apparently spare memory are

  • when under heavy I/O load the kernel has decided that pages that haven’t been used for ages is better swapped out so it can use the RAM for cache/buffers, though looking at your free output that is probably not the case here as you have a chunk of truly unallocated RAM as well as that used by IO cache/buffers.
  • the pages were swapped out for some reason earlier, and just hasn’t been needed again since – perhaps it is memory in use by a process that has been inactive for some time. In this case releasing the swap (so loading the pages back into RAM) may improve the response time of that process next time it is needed to do something other than sleep, but if it has been inactive for some time already it might not be needed at any time in the near future anyway.

Method 4

Remember that free is just a snapshot of memory usage. The result you are seeing may imply that, at some point in the past, the system was getting short of RAM so swapped-out RAM-resident material. Since then, RAM has become free but the material on swap has not been required so is still held on swap rather than just cluttering up RAM. If that is the case, turning off swap would be a bad idea. Are there any processes that could demand such a large amount of RAM since the last reload?

Additionally, you may want to check that you don’t have a restriction on maximum resident size set via ulimit (usually in /etc/profile but maybe it varies with distributions and it can be set per-process (e.g. in a launch script)).

Finally, on Microsoft Windows there are reports of specific issues with Firefox being swapped out to disk, e.g. when minimised (e.g. I’ve not heard of that on GNU/Linux systems but it may be worth exploring.

Note: Use and implement method 1 because this method fully tested our system.
Thank you 🙂

All methods was sourced from or, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0

Leave a Reply