How to Tune Linux Memory Swappiness for Better VPS Performance

vm.swappiness is a single kernel parameter that many VPS guides tell you to change — usually to 10 — without explaining what it actually does or why the default of 60 is a poor fit for servers. It is not a “percentage of RAM that will be swapped.” It is a weighting the kernel uses when it must reclaim memory: how willing it is to evict anonymous (process) memory to swap versus dropping file-backed page cache. Get it wrong and you either swap under no real pressure (wasted disk I/O) or starve the page cache (re-reads from disk). This guide shows how to measure, set, and verify swappiness for typical VPS workloads.

What swappiness actually controls

When RAM is full, the kernel must reclaim memory from one of two main pools: page cache (clean copies of files on disk — cheap to drop, but re-reading costs I/O) and anonymous pages (process heap and stack — they must be written to swap before the page can be reused, or the process gets killed by the OOM killer). The swappiness value, on a scale of 0 to 100, biases this choice: low values make the kernel prefer dropping page cache and avoid swapping anonymous memory; high values make it more willing to swap.

The default of 60 was chosen for general-purpose desktops. On a server with a fixed workload, 60 makes the kernel swap pages that are cold but not frozen, producing extra disk I/O for no benefit. One important correction: vm.swappiness=0 does not disable swapping — the kernel can still swap to avoid OOM. That is why modern practice says use 1 rather than 0 when you want “as little swapping as possible.”

Check your current value

• sysctl vm.swappiness — prints the current value (typically 60)
• cat /proc/sys/vm/swappiness — same value, direct from the kernel
• swapon --show — confirm swap actually exists; with no swap device, swappiness has nothing to act on

If there is no swap configured, set that up first — either a swapfile or zram — before tuning anything. Our swapfile vs zram setup guide covers creation, sizing, and monitoring.

Setting swappiness persistently

1. Apply immediately (until reboot): sudo sysctl -w vm.swappiness=10
2. Make it persistent: create /etc/sysctl.d/99-swappiness.conf containing vm.swappiness=10
3. Reload: sudo sysctl --system
4. Verify: sysctl vm.swappiness should now print 10

Sysctl files under /etc/sysctl.d/ are applied in lexical order and later files win, so the 99- prefix guarantees your override beats distro defaults.

Which value for which workload

Workload	Recommended swappiness	Why
General web/app server with adequate RAM	10	Page cache stays useful; disk I/O minimized
Database (MySQL/PostgreSQL)	1–10	Avoids swapping hot buffer-pool pages; 1 ≈ swap only to avoid OOM
Memory-spike apps (build servers, workers)	10–30	Lets the kernel park cold pages during bursts without thrashing
Tiny VPS (1–2 GB RAM) under constant pressure	10–20	Compromise; if pressure is sustained, the real fix is more RAM
Desktop / interactive session	60 (default)	Desktop responsiveness benefits from the stock behavior

Why lower swappiness helps — and when it won’t

On a VPS the win is mostly about I/O. Swap traffic shares your disk with the database, web server, and logs. Lowering swappiness keeps anonymous pages in RAM longer, so the kernel drops page cache instead — and page cache can be re-populated with one sequential read, while swapped pages cost random I/O in both directions.

The catch: if your server is already under genuine memory pressure — PSI memory some avg10 above 10%, or continuously non-zero si/so in vmstat 1 — swappiness tuning will not save you. You are out of RAM; add RAM or shrink the footprint. Swappiness is a reclaim-policy dial, not a memory multiplier. Before tuning, record a baseline with free -h, vmstat 1, and cat /proc/pressure/memory.

Verifying the change helped

1. Record a baseline: si/so over 24 hours plus application latency percentiles.
2. Apply the new value and wait 24–48 hours — reclaim behavior needs time to show up in metrics.
3. Compare: si/so should be lower or unchanged, and page-cache hit ratios (InnoDB buffer pool stats, nginx cache hits) should not regress.
4. If latency got worse, revert: sudo sysctl -w vm.swappiness=60 and remove the sysctl.d file.

Do not expect free -h to show more available RAM. Swappiness does not free memory — it changes where reclaimed pages come from.

cgroups v2 and containers

On cgroup v2 systems (Ubuntu 22.04+, Debian 12+, most current images), the host-wide vm.swappiness applies to the root cgroup. Containers can override it per-cgroup via the memory.swappiness file in their cgroup directory. For a plain VPS running services directly on the host, tuning the global value is sufficient; if you run Docker, be aware containers inherit the host value unless you set memory.swappiness explicitly.

Common mistakes

• Tuning swappiness with no swap configured — the parameter does nothing.
• Setting 0 expecting “no swap ever” — the kernel still swaps to avoid OOM; use 1.
• Expecting it to fix genuine RAM exhaustion — measure PSI first.
• Copying “swappiness=10” without checking the workload — a memory-spike app may need 30.

Swappiness is one small knob in a larger memory strategy, and the best tuning is buying the right amount of RAM in the first place. See the full specs and pricing for memory and storage options, and compare providers on our comparison table so you pick a box with enough headroom that this knob rarely matters.