Linux Performance: Why You Should Almost Always Add Swap Space

We know that using swap space instead of RAM can severely slow down the performance of Linux. So then, one might ask, since I have more than enough RAM available, wouldn’t it better to remove swap space completely? The short answer is, No. There are performance benefits when swap is enabled, even when you have more than enough ram.
With more than adequate RAM installed, you will often find that after a long periods of uptime, swap space will be used. See the below example from a live support chat server:

              total        used        free      shared  buff/cache   available
Mem:           3.7G        1.0G        445M         84M        2.2G        2.2G
Swap:          1.8G        308M        1.5G

The output of free -h here shows 308M of swap space used. When I ran checks for swapping there were no signs of ongoing or untimely swap I/O activity. In addition, the kswap service didn’t consume much CPU time. In fact, the kswap process was no where to be found in top (top processes sorted by CPU time). To confirm I used the following command:

ps -A | grep kswap
 40 ? 00:00:29 kswapd0

..so again swap, although used, is not hurting server performance. But lets look at how swap space can actually help Linux performance.

Advantages of swap space on systems with adequate RAM

It’s normal and can be a good thing for Linux systems to use some swap, even if there is still available RAM. The Linux Kernel will move memory pages which are hardly ever used into swap space to ensure that even more cached space is made available in-memory for more frequently used memory pages (a page is a piece of memory). Swap usage becomes a performance problem when the Kernel is pressured to continuously move memory pages in and out of RAM and swap space.
Another advantage is that swap gives admins time to react to low memory issues. We will often notice the server acting slowly and upon login will notice heavy swapping. Without swap (as described in the next section) running out of memory can create much more sudden and severe chain reactions. Of course, if you set your swap space too large. For example, a 64GB server with 64GB of swap, then it will take forever for some issues to max out the swap space. So usually I would advice to set swap space to about the size of your largest process. For example, MySQL’s configured memory in my.cnf. It can even be smaller. Especially if you have monitoring and/or alerting in place.
Some recommend swap size slightly larger than total RAM. If you can come up with valid reasons for this, then that may be your choice. However, on servers, this is hardly the case and you should instead balance your decision with the effects swap will have on your specific applications. Swap does not change the amount of RAM required for a healthy server, or desktop for that matter. It’s designed to be complimentary to performance on healthy systems.
To summarize:
— Even if there is still available RAM, the Linux Kernel will move memory pages which are hardly ever used into swap space.
— It’s better to swap out memory pages that have been inactive for a while, keeping often-used data in cache and this should happen when the server is most idle, which is the aim of the Kernel.
— Avoid setting your swap space too large if it will result in prolonging performance issues, outages or your response time (without proper monitoring/alerts).

Swap Space vs No Swap when available memory is low

Unlike the case above, if you don’t have enough memory, swap will be used quite often and noticeably more during any memory requirement spikes. If you don’t have enough memory and no swap space, this will often cause failure to allocate memory for requests needing more memory pages. As a last resort, the Kernel will deploy OOM killer to nuke high-memory processes (usually MySQL, java, etc).
For a more detailed look at Linux swap space read the Swap Management and Page Frame Reclamation chapters from Kernel.org docs. Also, have a look at the last section “Kernel cache pressure and swappiness” of my other blog post for tips on tuning the usage of Linux swap space by the Kernel. If your swap space “used” is always ‘0’ then you do indeed have a ton of freely available RAM, in which case it may be safe to remove the swap space… or you can adjust your Kernel’s cache pressure to make use of even more RAM.
To summarize:
— Swap I/O scales very poorly. If memory pages cannot be swapped only when the server is idle, then you should tune or disable swap. This is usually not the case, thus the “almost always” title of this blog post.
— With swap disabled, performance issues become noticeable very fast and the OOM killer may get you! :)
For comparison, here’s the output of free using and older version of free from procps-ng-3.3.1 on the same server:

             total       used       free     shared    buffers     cached
Mem:          3.7G       3.3G       445M         0B       4.2M       1.7G
-/+ buffers/cache:       1.6G       2.1G
Swap:         1.8G       308M       1.5G

The man pages for both versions of free should be considered independently (see screenshot of the most recent version below).