Configuring Swap on a VPS: Sizing, swappiness, and Measuring Memory Pressure

Swap on a VPS is either treated as untouchable folklore or configured on autopilot — a 2 GB swapfile because that is what a tutorial once said. Both approaches ignore the actual mechanics. Swap is not a performance feature; it is a safety valve that trades disk latency for the ability to survive a memory spike. Whether that trade is a good deal depends entirely on your storage medium, your workload’s access patterns, and how the kernel’s page-reclaim heuristics behave under pressure.

What Swap Actually Buys You

The kernel moves pages to swap for two different reasons, and conflating them causes most of the bad advice. First, anonymous pages that have been idle can be evicted to make room for page cache — this is cheap and often improves throughput. Second, under genuine memory pressure the kernel is forced to swap out active working sets, and that is what produces the infamous multi-second stalls. You want the first behaviour and want to avoid the second. A well-tuned server rarely faults pages back in from swap except at startup after a reboot.

Sizing: The Arithmetic Beats the Rule of Thumb

The traditional “2x RAM” rule was written for systems with 512 MB of memory and spinning disks. On a modern instance the useful sizing question is: how much headroom do I need to absorb a spike while an operator intervenes? For a 1 GB instance running a web stack, 1–2 GB of swap is plenty; more just delays the inevitable OOM kill while thrashing the disk. For a 4 GB database host, 2–4 GB is a reasonable emergency reserve. If you are unsure how much memory your workload genuinely needs, this guide to VPS plans and resource allocation is a better starting point than guessing at swap size.

Verify the current configuration before changing anything:

swapon --show; free -m; cat /proc/sys/vm/swappiness; vmstat 1 5

The vm.swappiness Question

vm.swappiness controls the relative cost the kernel assigns to reclaiming page cache versus swapping anonymous pages. It is not a simple on/off dial. On an NVMe-backed instance a value of 10–20 keeps the kernel biased toward cache eviction while still allowing swap under real pressure. Setting it to 0 does not disable swapping — it only discourages it until the situation is dire, at which point reclaim becomes more aggressive and the stall is worse, not better. Measure the effect rather than copying a number: watch vmstat columns si and so during a realistic load.

Swapfile vs zram vs a Dedicated Partition

A swapfile on the same filesystem as your data is the simplest option but shares I/O with everything else. A zram device compresses pages in RAM, giving you effective capacity at zero disk latency — excellent for small instances where the alternative is OOM penalties, but it consumes CPU and does nothing if the compressed data would not fit. A dedicated swap partition avoids filesystem fragmentation issues but is inflexible. On most VPS workloads a modest swapfile plus a small zram device covers both the “survive the spike” and “cheap eviction” cases.

Measuring Whether Swap Is Helping or Hurting

The decisive metric is not how much swap is used but the rate of swap-in. Sustained si above a few hundred KB/s during normal operation means your working set does not fit in RAM and swap is masking a capacity problem — add memory or reduce the footprint. Occasional bursts followed by long idle periods are healthy. Combine this with cat /proc/pressure/memory, which reports the percentage of time tasks were stalled on memory reclaim. If that number climbs during peak hours, swap is no longer a safety valve; it is a symptom.

Configure swap deliberately, size it from your workload rather than a slogan, and watch the pressure counters instead of the raw usage figure. Combined with the right memory allocation for your VPS, this keeps swap serving its purpose: an emergency buffer that buys you time, not a substitute for adequate memory.