Adding swap to a server running low on memory seems like an obvious fix: more room available before a process gets killed. In practice, swap often shifts the problem toward a worse form, a system rendered unusable by thrashing, rather than solving it cleanly.

What swap actually does under memory pressure

The kernel moves the least recently used memory pages to disk when physical RAM runs low, freeing room for what’s actually active. This mechanism works fine for rarely accessed pages, but becomes a problem the moment a process keeps actively accessing pages that have been swapped out: every access triggers a disk read, orders of magnitude slower than a RAM access.

Thrashing: the entire system becomes unusable

Under heavy memory pressure, several active processes can end up competing for the same swap space: the kernel then spends most of its time writing and re-reading pages from disk rather than running application code, a state called thrashing. Unlike a process cleanly killed by the OOM killer, a thrashing system stays technically alive, but becomes so slow that any action (including an SSH connection to diagnose the problem) can take several minutes.

# A thrashing system shows massive disk activity
# with no correlation to actual application load
vmstat 1
# si si  bi   bo   in   cs us sy id wa
#  8  4 512  256 4000 8000  5 15  0 80
# high wa (I/O wait) = classic thrashing symptom

vm.swappiness: the dial that decides aggressiveness

vm.swappiness (0 to 100, 60 by default on many distributions) controls how much the kernel prefers swapping pages over reclaiming memory through other means (shrinking disk cache, for instance). A low value delays reaching for swap, preferring to shrink system cache first; a high value swaps sooner and more aggressively.

# Current value and temporary adjustment
# (not persistent across reboot)
cat /proc/sys/vm/swappiness
sysctl vm.swappiness=10

The modern recommendation: minimal or no swap on servers

On an application server (as opposed to a workstation, where swap absorbs occasional spikes without hurting perceived responsiveness), modern practice often leans toward a very low swappiness, or no swap at all: letting the OOM killer act quickly and cleanly kill the most problematic process is often better than a system thrashing indefinitely without ever actually relieving memory pressure.

# Disabling swap entirely,
# a common practice on production servers
swapoff -a

This recommendation isn’t universal: a database or an application with short, occasional memory spikes can legitimately benefit from some swap to absorb those spikes without triggering the OOM killer, a trade-off to evaluate against the actual load profile, not a rule to apply blindly.

Takeaway

Swap moves memory pressure to disk, a mechanism that works for rarely accessed pages but degenerates into thrashing when several active processes compete for the same space: the system stays technically alive, but becomes so slow that even diagnosing it becomes hard, often worse than a process cleanly killed by the OOM killer. vm.swappiness controls how aggressively swap gets used, a low value or full disabling often being preferable on a modern application server, at the cost of a quicker-to-act OOM killer on occasional memory spikes. This trade-off, rarely obvious at first glance, is one of the Linux settings that matter the moment a server runs under genuine memory pressure.