Swap is an area of disk storage that the operating system uses as an extension of physical memory, moving rarely used memory pages out of RAM so that active processes keep the fast memory they need. Among server resources, swap sits between RAM and the OOM killer: it absorbs short memory spikes and idle allocations, but it is orders of magnitude slower than RAM and cannot replace adequate memory sizing.
On Linux servers swap takes the form of a swap partition or a swap file, and the kernel decides page by page what to evict. On Windows the equivalent is the page file. Understanding swap means understanding memory pressure, page reclaim and the cost of disk latency.
How swap works inside the kernel
Swap works through page reclaim: when free memory drops below kernel thresholds, the memory manager scans its page lists and chooses pages to evict. File-backed pages, such as cached program files, can simply be dropped and reread from disk later. Anonymous pages, such as heap and stack data, have no file behind them, so the kernel must write them to swap before it can free the RAM.
When a process later touches a swapped-out page, the CPU raises a major page fault. The kernel suspends the thread, reads the page back from swap and resumes execution. On a solid-state drive this costs roughly tens to hundreds of microseconds; on a rotating disk it can cost several milliseconds, compared with about 100 nanoseconds for a RAM access.
The following table compares the storage layers involved in a swap decision and why the latency gap matters.
| Layer | Typical access latency | Relative to RAM |
|---|---|---|
| RAM (DRAM) | About 100 ns | Baseline |
| NVMe SSD swap | About 20-100 µs | Hundreds of times slower |
| SATA SSD swap | About 100-200 µs | Roughly a thousand times slower |
| HDD swap | About 5-10 ms | Tens of thousands of times slower |
| zram (compressed RAM) | A few µs | Slower than RAM, far faster than disk |
Swap parameters and configuration options
The behavior of swap on Linux is shaped by a few tunable parameters and by the type of swap device. The most discussed is vm.swappiness, which sets the relative preference for reclaiming anonymous pages versus file cache; it does not set a memory percentage at which swapping begins, which is a common misconception.
| Setting | Typical range | What it affects |
|---|---|---|
| vm.swappiness | 0-200, default 60 | Balance between swapping anonymous pages and dropping file cache |
| Swap size | 0 to 1-2x RAM | How much overflow capacity exists before the OOM killer acts |
| Swap priority | -1 to 32767 | Which swap device the kernel fills first |
| vm.vfs_cache_pressure | Default 100 | How eagerly directory and inode caches are reclaimed |
| memory.swap.max (cgroup v2) | 0 to unlimited | Per-service cap on swap usage |
A swap file is easier to resize than a swap partition and performs similarly on modern file systems, although some file systems impose restrictions such as no copy-on-write. zram creates a compressed block device in RAM and is popular on small virtual machines, while zswap adds a compressed cache in front of a disk-based swap device.
Swap compared with related memory mechanisms
Swap is one of several ways a server responds to memory pressure, and it is often confused with neighboring concepts. The table below separates them by what they do and when they act.
| Mechanism | What it does | When it acts |
|---|---|---|
| Swap | Moves anonymous pages to disk | Under gradual or sustained memory pressure |
| Page cache reclaim | Drops clean file-backed pages | First line of reclaim, very cheap |
| OOM killer | Terminates a process to free memory | When reclaim and swap cannot satisfy an allocation |
| Memory overcommit | Allows allocations beyond physical RAM | At allocation time, before pages are touched |
| Load average | Counts runnable and blocked tasks | Rises when swap I/O blocks processes |
The link to load average is practical: on Linux, tasks waiting for swap I/O are in uninterruptible sleep and are counted in the load figure, so a server can show high load with low CPU utilization when it is swapping heavily. That pattern is a classic symptom of memory starvation rather than a CPU shortage.
Sizing and using swap on production servers
The old rule of twice the RAM dates from machines with little memory and is rarely appropriate today. Modern sizing depends on workload, hibernation needs and how the operator wants the system to fail: slowly through swapping or quickly through the OOM killer.
| Situation | Recommended approach | Reason |
|---|---|---|
| Small VM, 1-2 GB RAM | Swap of 1-2 GB or zram | Absorbs spikes during package updates and builds |
| General application server | Modest swap, 2-4 GB | Lets idle pages leave RAM without masking leaks |
| Database server | Small swap, low swappiness | Buffer pools must stay resident for predictable latency |
| Latency-critical service | Little or no swap, strict limits | Fast failure is preferable to slow responses |
| Kubernetes node | Disabled or explicitly configured | Historically required off; newer versions support it with limits |
Monitoring should track swap-in and swap-out rates, not only the amount of swap used. A server can hold several gigabytes in swap harmlessly if those pages are never touched again, while a steady swap-in rate under load indicates that the working set no longer fits in RAM.
Limitations, risks and common mistakes
The central risk of swap is thrashing, a state in which the system spends more time moving pages between RAM and disk than doing useful work. Response times climb from milliseconds to seconds, and the server may become unreachable over SSH long before the OOM killer intervenes.
- Treating swap as extra RAM: swap only helps when the moved pages are cold; it cannot serve an active working set.
- Setting swappiness to zero blindly: this can make reclaim more abrupt and trigger the OOM killer earlier than expected.
- Ignoring swap I/O on shared storage: on cloud volumes, swap traffic consumes IOPS and throughput quotas shared with application data.
- Leaving sensitive data unencrypted: pages written to swap may contain keys or passwords, so encrypted swap is advisable on sensitive systems.
- Disabling swap entirely without memory limits: the first memory spike then ends in an immediate process kill.
Stripped to the essentials
Swap is a storage room for memory. A server keeps the work it is actively doing on its desk, which is RAM. When the desk gets full, it moves papers it has not touched in a while into a storage room on disk, so there is space for current work.
The storage room is useful, but walking to it is slow. If the server keeps needing the papers it just put away, it spends all its time walking back and forth and gets very little done. Swap is a safety margin, not a substitute for enough memory.
Where it is applied
A small company runs its web application on a cloud virtual machine with 2 GB of RAM. Every night a backup script and a log compression job start together, and memory use briefly exceeds what the machine has. Without swap, the OOM killer terminates the database process roughly once a week.
The administrator adds a 2 GB swap file with vm.swappiness set to 10 and enables monitoring of swap-in rates. During the nightly jobs the kernel moves idle pages of rarely used services to swap, the jobs complete a few minutes slower, and the database is no longer killed. Daytime swap-in rates stay near zero, which confirms that the working set still fits in RAM.