Tuning Linux Swap on an NVMe VPS Without Causing Latency Spikes

Swap has a bad reputation on servers, and mostly for good reason: if a workload actively pages to a slow disk, latency explodes. But swap is not inherently harmful. On an NVMe-backed VPS, a small, correctly configured swapfile can absorb bursty memory spikes, keep the OOM killer away, and preserve cache for hot data. This guide walks through configuring swap so it helps rather than hurts.

When swap helps on an NVMe VPS

• Short-lived memory spikes above the RAM ceiling that would otherwise trigger the OOM killer.
• Cold anonymous pages that are rarely touched and can live on disk harmlessly.
• Predictable graceful degradation during traffic bursts instead of abrupt process death.

When swap hurts: sustained pressure where the working set genuinely exceeds RAM. In that case you are not swapping occasionally, you are thrashing, and no amount of NVMe speed fixes a workload that does not fit. The correct fix is more memory, not more swap. If that describes your situation, right-sizing the instance is the real solution, and our VPS comparison helps identify a tier with adequate RAM.

Configuring a swapfile

fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

# persist
echo '/swapfile none swap sw 0 0' >> /etc/fstab

# verify
swapon --show
free -h

Size is workload-dependent. A common starting point is equal to RAM for small instances under 2GB, and half of RAM above that. The goal is headroom for spikes, not a second main memory tier.

Tuning swappiness for NVMe

vm.swappiness controls how eagerly the kernel reclaims anonymous pages versus page cache. The default of 60 is tuned for desktop responsiveness, not servers. On a VPS with fast NVMe, a moderate value keeps the OOM killer away without excessive paging.

swappiness	Behavior	Use case
0	Nearly avoids swap until OOM	Latency-critical, RAM-rich
10	Swaps only under real pressure	Typical VPS server default
60	Balanced, desktop-tuned	Interactive desktops
100	Aggressive	Rarely appropriate

# runtime
sysctl vm.swappiness=10

# persistent
echo 'vm.swappiness=10' > /etc/sysctl.d/99-swap.conf
sysctl --system

Also consider vm.vfs_cache_pressure if you notice inode and dentry caches being evicted too aggressively under pressure; a lower value (say 50) retains them longer.

Measuring whether swap is hurting you

The signal that matters is swap-in rate, not swap utilization. A system using 800MB of swap but never swapping back in is fine. A system swapping in tens of MB per second is thrashing. Watch si and so in vmstat over time.

vmstat 1 20
# si/so near 0  -> swap is dormant, fine
# si/so sustained > few hundred KB/s -> active paging, investigate

# per-process swap
for f in /proc/*/status; do awk \
  '/^Name/{n=$2}/^VmSwap/{if($2>0)print n,$2"kB"}' "$f"; \
done | sort -k2 -n | tail

Persistent swap-in under load tells you the working set does not fit. Mitigate by reducing memory consumers or moving to a larger instance. The technical companion is the managed vs unmanaged breakdown, useful when deciding whether to hand tuning and monitoring off to a provider.

Guarding against swap-induced latency spikes

• Place the swapfile on NVMe, never on a network or SATA volume.
• Keep swappiness low (10) so warm pages stay in RAM.
• Pin latency-critical services with cgroup memory limits so they cannot be evicted wholesale.
• Monitor si/so alerts rather than swap occupancy.

Swap is a safety buffer, not a performance feature. Configure it deliberately, keep it dormant under normal load, and treat any sustained swap-in as a memory-sizing signal. Done that way, it prevents OOM kills without reintroducing the latency problems that gave swap its bad name.