Should you disable swap on a server? The honest answer

Key takeaways

• Swap is not only there to paper over a memory shortfall: it lets the kernel evict pages that are never used and hand that room back to the cache.
• Without swap, those inert pages stay resident in RAM and shrink the disk cache, which hurts performance.
• Swappiness is not a memory percentage: it is a trade-off between evicting cache and evicting anonymous pages.
• Slowness blamed on swap almost always comes from a genuine shortage of memory, not from swap itself.
• Legitimate reasons to disable it: hard latency guarantees, and certain orchestrators that require it.

The advice has been going around for twenty years: on a properly sized server, disable swap. It sounds solid enough. If you have enough memory, why use a disk that is a thousand times slower?

It rests on a confusion: swap fills two distinct roles, and the argument only considers one of them.

The two roles of swap

Role one: the relief valve. When memory runs short, swap avoids a hard failure by moving pages out to disk. That is the role everyone knows about, and indeed, with enough memory it should never come into play.

Role two: optimization. This is the one people forget. A running system accumulates pages that were allocated but never read again: initialization data, libraries loaded and then left untouched, dormant daemons that will not wake up for days.

Those pages occupy RAM without doing the slightest bit of useful work. With swap available, the kernel moves them out to disk and reclaims that memory for the disk cache.

And the disk cache speeds up everything. Every megabyte handed back to the cache is physical reads you never have to perform.

Swappiness does not do what you think

The most-discussed tunable is also the most misunderstood. The common belief: that it is a memory-usage percentage above which the system starts swapping.

It is not that. The parameter expresses a trade-off: when the kernel has to free memory, would it rather evict disk cache or anonymous pages?

A low value pushes it to sacrifice cache. A high value pushes it to sacrifice anonymous pages to swap. No trigger threshold is defined anywhere.

Practical consequence: setting it to zero does not disable swap. It tells the kernel to fall back on it only as a last resort, which under heavy pressure will happen anyway.

And a very low value has a perverse effect: the kernel would rather throw away disk cache, including cache that is genuinely useful, than move out pages that have been asleep for three weeks. You keep in memory what is not being used, and you re-read from disk what is.

Swap is a symptom, not a cause

The most common line of reasoning: "the server is crawling, swap is in use, therefore it is the swap."

It is the reverse. If the system is actively paging in and out non-stop, it is because physical memory no longer covers the workload. Swap does not cause the slowdown: it makes it visible, while cushioning a situation that without it would end in killed processes.

Hence an essential distinction when diagnosing:

• The amount of swap in use is often benign. A few hundred megabytes on a server that has been up for months is inert pages, correctly filed away. Nothing to do about it.
• Swap activity, pages moving in and out continuously, is the real signal. That is what points to an actual shortage.

Monitor swap throughput, not swap occupancy. Alerting on the latter generates permanent false positives.

Where disabling it is justified

Two legitimate situations.

Workloads with hard latency guarantees. Real-time processing, a fully in-memory database, an application where an unexpected disk access breaks a service commitment. There, a clean and immediate failure beats erratic latency that nobody can account for.

Certain container orchestrators. Several require it to be off, for a defensible reason: swap makes container memory limits unpredictable and skews placement decisions. A container that is supposed to be capped at two gigabytes but uses three by way of swap breaks the whole scheduling model.

Outside those cases, disabling swap rarely delivers the expected gain, and it often costs you disk cache.

In-memory compression, a good compromise

There is a middle road that sees far too little use: compressing pages in memory instead of writing them out to disk.

Pages that are candidates for swap get compressed and kept in a dedicated region of RAM. You reclaim space without paying the disk latency, at the cost of a little CPU, a resource that is generally available on a memory-constrained server.

On a machine that sees occasional spikes, this absorbs most of them at a penalty nowhere near that of conventional swap. It is not a substitute for missing memory, but it is an effective intermediate layer.

The recommendation

Keep some swap, sized modestly. A few gigabytes is plenty on a well-provisioned server. Its purpose is not to compensate for a shortfall, but to leave the kernel free to file away what is not being used.

Leave swappiness at its default unless you have measured otherwise on your real workload. Monitor swap activity rather than occupancy. And if that activity is sustained, do not touch the swap: add memory. It is the only change that treats the cause.