vm.swappiness on a VPS: What the Kernel Actually Does and How to Measure It

vm.swappiness is the single kernel knob most VPS guides tell you to set to 10 and then forget. That advice is not wrong, but it is cargo-cult: it explains the value, not the mechanism. Swappiness is a relative reclaim weight, not a percentage of RAM. Understanding what it biases lets you choose a value for your workload instead of copying one from a forum post. This guide covers the reclaim model, how to measure the effect under real pressure, and how to verify the change actually took effect.

The reclaim decision swappiness controls

When free memory runs short, the kernel reclaims from two pools. File-backed page cache is cheap to discard — it is a clean copy of something already on disk, but re-reading it later costs I/O. Anonymous pages (heap and stack) cannot simply be dropped; they must be written to swap first, or the process dies under the OOM killer. Swappiness on a 0–100 scale biases that choice. Low values push the kernel toward dropping clean cache before touching anonymous memory. High values make the kernel more willing to swap. The default of 60 was tuned for desktop interactivity, where a burst of swapping beats re-reading application binaries. A fixed server workload has different economics.

Why 60 is usually wrong on a server

On a VPS you typically know which pages matter. A database with a large resident working set does not want that working set paged out to satisfy a filesystem scan. A web front-end with a warm page cache would rather keep cached assets than push long-idle PHP workers into swap. The server-tuned value of 10 tells the kernel: only swap once reclaim from cache has been exhausted. That is the right default for most VPS roles. The exceptions are workloads with a genuinely cold, large anonymous footprint — batch jobs and idle daemons — where letting some of it swap frees cache for hot data.

Set and persist the value

Change it at runtime for a test, then persist it:

sysctl -w vm.swappiness=10
echo 'vm.swappiness=10' | sudo tee /etc/sysctl.d/99-swappiness.conf
sysctl --system

Confirm the running value rather than trusting the file: cat /proc/sys/vm/swappiness. A container may mask or override the host value, so verify inside the workload namespace if you run one.

Measure the effect instead of guessing

The right way to validate any swappiness change is to watch swap-in rate during steady-state load, not total swap used. Swap that filled once and never moves again is harmless; continuous swap-in is what causes latency spikes. Track it:

vmstat 1 10        # si/so columns: swap-in and swap-out per second
grep -E 'pswpin|pswpout' /proc/vmstat

A healthy tuned server shows si and so near zero after warm-up. Persistent nonzero swap-out under moderate load means the anonymous working set exceeds RAM and no swappiness value will save you — you need more memory or a smaller working set. Pair the measurement with PSI to see whether memory pressure, not swap, is the bottleneck:

cat /proc/pressure/memory

The zero-swappiness myth

A persistent piece of advice claims vm.swappiness=0 disables swapping entirely. It does not. On modern kernels 0 means swap is used only to avoid an out-of-memory condition — an emergency valve, not a wall. If you set 0 and the anonymous working set still exceeds RAM, the kernel swaps anyway (or OOM-kills); you have removed the gradual, graceful reclaim that could have bought you time. A value of 0 is defensible for a latency-critical database where any swap-in is unacceptable and you have sized RAM with margin; it is a poor default for a general web host, where the occasional cold page swapping out is cheaper than an OOM kill. Choose 0 only with monitoring in place to alert on pswpin the moment it moves.

Page cache versus swap on shared storage

The decisive factor is often the backing device, not the number. On a VPS with a shared NVMe swap file, a swap-in is a random read that competes with every other tenant’s database I/O on the same physical device — latency is unpredictable and can spike into the tens of milliseconds. Dropping a clean page-cache entry costs nothing but a future re-read, which on the same device is equally priced. This asymmetry is why the answer is workload-specific: if your hot data lives on that device anyway, keeping cache and avoiding swap is a wash, so lean low. If your working set is small and fits in RAM, swappiness barely matters because reclaim rarely runs. Measure /proc/vmstat over a full day before deciding you have a swap problem at all.

Interactions you should not ignore

Swappiness does not act alone. vm.min_free_kbytes controls the reserve the kernel keeps to satisfy atomic allocations — too low and you get allocation stalls before reclaim even starts. If you run zram, the “swap” device is compressed RAM, so swap-in is much cheaper and a higher swappiness can be defensible. On a swap file hosted on shared NVMe, swap-out competes with database I/O, which is precisely why the low-swappiness default exists. When you are sizing a plan to leave enough headroom to avoid swapping altogether, our VPS comparison page breaks down RAM-per-dollar and disk type per tier. If you are still deciding between instance sizes, the same page covers which configurations include dedicated CPU and NVMe versus shared storage. With performance VPS plans you can compare which tiers ship with enough RAM and NVMe to make the low-swappiness default comfortable. The one-line rule: default to 10, raise it only when the anonymous working set is deliberately cold, and lower it further only after proving swap-in is negligible.