Swap Space on a VPS: How Much to Configure and When It Hurts Performance

Swap is the most misunderstood resource on a small VPS. Configured correctly, it is a safety net that prevents the OOM killer from terminating your database during a traffic spike. Configured as a substitute for RAM, it turns your server into a thrashing disk-bound machine that is slower than the shared hosting you left behind. The old “2x your RAM” rule from the 2000s no longer applies to modern VPS workloads, and the right answer depends on your RAM tier, your application, and whether you use zram. This guide covers swap file vs partition, sizing by RAM tier, the swappiness setting, and how to tell when swap is masking a real memory problem. If your provider’s smallest plan forces constant swap usage, our provider comparison table can help you find one with adequate RAM for the same budget.

What swap actually does

Swap is disk space that the kernel uses as an overflow for memory pages. When physical RAM fills up, the kernel writes cold pages to swap and reclaims their RAM for active work. Reading a page back from disk is orders of magnitude slower than reading it from RAM (a modern NVMe delivers ~2 GB/s; RAM delivers 20–50 GB/s with far lower latency), so the goal is to use swap rarely and temporarily, not continuously.

How much swap: sizing by RAM tier

Modern sizing guidance depends on total RAM and what the workload is:

VPS RAM	Recommended swap	Rationale
512 MB – 1 GB	1–2 GB	Needed as a real overflow; keep swappiness low
2 GB	1–2 GB	Safety net for spikes; not a RAM substitute
4 GB	1–2 GB	Mostly for OOM safety during brief peaks
8 GB+	0–2 GB or zram	Swap rarely helps; consider zram instead

These values assume a typical web or database workload. A server running in-memory caches (Redis with maxmemory set correctly) should never need disk swap at all.

Swap file vs swap partition

On modern Linux, a swap file is the better default on a VPS. You can create, resize, or remove it without repartitioning the disk, which matters when your provider’s console does not expose partition tools. A swap partition survives some edge cases (for example, swap on a separate disk that the root filesystem cannot mount) and is preferred in a few embedded or boot-critical setups, but for a standard VPS the file is simpler and equally fast on SSD/NVMe. Create a 2 GB file with fallocate -l 2G /swapfile, secure it with chmod 600 /swapfile, run mkswap /swapfile, enable it with swapon /swapfile, and add it to /etc/fstab with the sw option so it survives reboots.

Swappiness: the setting everyone argues about

vm.swappiness (0–100) controls how aggressively the kernel moves anonymous memory pages to swap. The default of 60 is too high for most VPS workloads; it causes the kernel to swap under moderate pressure when it should instead drop clean page cache. Set vm.swappiness = 10 in /etc/sysctl.d/99-vps.conf (sysctl -p to apply) for most servers: the kernel keeps working set pages in RAM and only swaps when pressure is genuine. Keep it near 0 on database servers, and consider values of 20–40 only on RAM-starved boxes that must stay alive during spikes. Also set vm.vfs_cache_pressure = 50 if you want the kernel to retain inode/dentry caches longer under memory pressure.

When swap hurts performance

Swap becomes a liability in three situations. First, thrashing: when the working set exceeds RAM, the kernel continuously writes and reads pages, and throughput collapses to disk speed; the server looks “busy” but nothing completes. Second, latency amplification: a single swapped-out page fault can add 10–100 ms to a request that would take 1 ms in RAM. Third, and most important, masked problems: if swap usage grows steadily over days, you have a memory leak or an undersized allocation, and adding more swap just postpones the crash while degrading every request. Diagnose with free -h (watch the si/so columns in vmstat 5 for active paging) and check dmesg for OOM-killer events.

zram: the modern alternative on small VPS

zram creates a compressed block device in RAM and uses it as swap. Compression typically gives 2–3x effective memory for compressible data, and because it never touches disk, it avoids the latency cliff entirely. It is the right choice on 512 MB–2 GB VPS plans where disk-backed swap would thrash. Set zram0 to about half your RAM (for example, 1 GB on a 2 GB VPS) and keep a small disk swap file as a final fallback. The kernel handles the zram-to-disk overflow automatically. Note that zram consumes CPU for compression, so it suits modest workloads better than heavy database loads.

Monitoring and fixing the real problem

• free -h — total, used, and swap usage at a glance.
• vmstat 5 — si/so columns show actual pages swapped in/out; sustained non-zero values mean real paging.
• dmesg | grep -i oom — reveals OOM-killer activity that swap should have prevented.
• systemctl status and per-process RSS (ps aux --sort=-rss | head) — find the process that is leaking or over-allocating.

If monitoring shows continuous paging, the fix is more RAM or a smaller workload, not more swap. When your application’s memory needs outgrow the plan, upgrading RAM on most providers takes minutes; compare RAM-per-dollar across hosts in our provider comparison table before you pay for another month of thrashing.

If you would rather have a platform where memory sizing and scaling are handled for you, Cloudways manages the underlying VPS and lets you scale RAM vertically in a few clicks without reconfiguring swap yourself. Start a free Cloudways trial and test your workload against properly sized instances.