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
Why You Should Almost Always Add Swap Space #linuxClick To Tweet
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 recommended a swap of a size equal to the RAM, or even twice the RAM. If you can come up with valid reasons for this, then that may be your choice. Balance your decision with the effects of large swap space usage to your application or service and if maxing out a small swap space vs a large one will change the end result or just delay it maybe too long.
— It’s better to swap out a memory pages that have been inactive for a while and instead keep often-used files in cache and to do this 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 process(es). (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.
— 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).