Linux VM running nginx (or any other light-weight daemon with stable resource usage). VM is allocated 2GB of memory with 200-300MB used by OS and services with the rest for file cache and buffers. In one specific use-case I expect an easy 500MB overhead.

Q: Why would this setup need swap space?

The standard answer of "To prevent memory exhaustion" doesn't make sense to me here for 2 reasons: 1: the demand for memory is well established and does not need to support an unexpected or sudden significant increase. 2: Swap only delays OOM situation in any case. The same thing can be accomplished by assigning more memory to the VM in the first place, especially since it's thin provisioned any nobody will miss out on it as long as it's unused.

The other common answer to support hibernation doesn't apply to a server in a VM.

I see no reason for swap on such a server; am I missing something?

2 Answers 2


You shouldn’t think of “having swap” or not, you should consider your overall memory allocation strategy and determine whether or not swap is necessary. There are two main aspects to this.

The primary purpose of swap nowadays isn’t to extend physical memory, it’s to provide a backing store for otherwise non-reclaimable pages (e.g. memory allocations and anonymous mmaps). If you run without swap, you force the kernel to keep anonymous memory in physical memory, which reduces its ability to cope with varying memory needs. Obviously if you know your workload always fits in the available physical memory, this shouldn't be an issue.

The second aspect to consider is the kernel’s overcommit strategy. By default, memory allocations mostly succeed, regardless of the memory load. If you’re trying to control your workload though, it’s often helpful to run in checking mode (/proc/sys/vm/overcommit_memory set to 2); then commits are limited to the sum of swap, and physical memory not allocated for huge pages adjusted by the overcommit ratio (which is 50% by default). If you run without swap, nothing can ever allocate more than half the physical memory by default; adding swap increases that limit linearly, with less risk than increasing the overcommit ratio. (This often trips people up when attempting to run large-ish JVMs on typical server setups.)

I mentioned there are two main aspects, which are described above, but it occurs to me that there can be another point to consider in some cases (it’s really a variant of the first point): tmpfs file systems can easily get your system in trouble if there’s no swap...

For more on all this, I recommend reading the proc(5) manpage’s sections on overcommit, and Chris Down’s recent blog post in defence of swap.

  • Isn't your "second aspect" equally addressed by increasing the memory allocation to the VM? And great point on tmpfs, I didn't think of that. Luckily Ubuntu seems to make limited use of it as compared to other distros.
    – virullius
    Commented Jan 18, 2018 at 14:52
  • 2
    Increasing the memory allocation isn’t necessarily a good strategy to deal with overcommit: for example with a JVM configured with -Xmx8g, you need 16G allocated to the VM but you’ll never use much more than 8 (well 10 maybe), whereas 8G RAM + 4-6G swap would allow it to start fine. Commented Jan 18, 2018 at 15:01

You don't need the swap space, but there are a few points you didn't mention that are worth bearing in mind. Some pages which are loaded when the system starts will never be touched again. It's arguably better to leave them on disk rather than in ram, though any performance gain is probably tiny.

On a related note, some workloads such as the jvm allocate quite a bit of memory that may never be used. You can be throwing the baby out with the bathwater if your workload habitually overcommits. Limiting the kernel to physical memory may mean that you either a) allocate more RAM than the VM needs, wasting server resources which could go to other VMs or b) cause the kernel to reduce the amount of buffers in order to retain unused (or rarely used) allocated pages with the resulting increase in disk activity decreasing overall performance.

Without swap enabled you may find your overhead mysteriously vanishing if you need to log into the system for debugging. It really only takes one time logging into a system that combines tight starting memory constraints and a memory leak to encourage more liberal swap space policies. Taking an hour to do anything on a thrashing machine is still an improvement over the OOM killer constantly firing.

Finally, it's not uncommon in Unix systems for kernel dumps to be placed in swap. A fair number of administrators will still allocate enough swap to allow debugging a kernel panic. (Though apparently Linux offers a work around for this now.)

You must log in to answer this question.

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