{"id":882,"date":"2026-08-13T23:15:01","date_gmt":"2026-08-13T23:15:01","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=882"},"modified":"2026-08-13T23:15:01","modified_gmt":"2026-08-13T23:15:01","slug":"vps-swap-space-sizing-configuration-guide","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/vps-swap-space-sizing-configuration-guide\/","title":{"rendered":"Swap Space on a VPS: How Much to Configure and When It Hurts Performance"},"content":{"rendered":"\n

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<\/a> can help you find one with adequate RAM for the same budget.<\/p>\n\n\n\n

What swap actually does<\/h2>\n\n\n\n

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\u201350 GB\/s with far lower latency), so the goal is to use swap rarely and temporarily, not continuously.<\/p>\n\n\n\n

How much swap: sizing by RAM tier<\/h2>\n\n\n\n

Modern sizing guidance depends on total RAM and what the workload is:<\/p>\n\n\n\n

VPS RAM<\/th>Recommended swap<\/th>Rationale<\/th><\/tr><\/thead>
512 MB \u2013 1 GB<\/td>1\u20132 GB<\/td>Needed as a real overflow; keep swappiness low<\/td><\/tr>
2 GB<\/td>1\u20132 GB<\/td>Safety net for spikes; not a RAM substitute<\/td><\/tr>
4 GB<\/td>1\u20132 GB<\/td>Mostly for OOM safety during brief peaks<\/td><\/tr>
8 GB+<\/td>0\u20132 GB or zram<\/td>Swap rarely helps; consider zram instead<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

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

Swap file vs swap partition<\/h2>\n\n\n\n

On modern Linux, a swap file<\/strong> 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<\/strong> 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<\/code>, secure it with chmod 600 \/swapfile<\/code>, run mkswap \/swapfile<\/code>, enable it with swapon \/swapfile<\/code>, and add it to \/etc\/fstab<\/code> with the sw<\/code> option so it survives reboots.<\/p>\n\n\n\n

Swappiness: the setting everyone argues about<\/h2>\n\n\n\n

vm.swappiness<\/code> (0\u2013100) 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<\/code> in \/etc\/sysctl.d\/99-vps.conf<\/code> (sysctl -p<\/code> 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\u201340 only on RAM-starved boxes that must stay alive during spikes. Also set vm.vfs_cache_pressure = 50<\/code> if you want the kernel to retain inode\/dentry caches longer under memory pressure.<\/p>\n\n\n\n

When swap hurts performance<\/h2>\n\n\n\n

Swap becomes a liability in three situations. First, thrashing<\/strong>: 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<\/strong>: a single swapped-out page fault can add 10\u2013100 ms to a request that would take 1 ms in RAM. Third, and most important, masked problems<\/strong>: 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<\/code> (watch the si<\/code>\/so<\/code> columns in vmstat 5<\/code> for active paging) and check dmesg<\/code> for OOM-killer events.<\/p>\n\n\n\n

zram: the modern alternative on small VPS<\/h2>\n\n\n\n

zram creates a compressed block device in RAM and uses it as swap. Compression typically gives 2\u20133x 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\u20132 GB VPS plans where disk-backed swap would thrash. Set zram0<\/code> 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.<\/p>\n\n\n\n

Monitoring and fixing the real problem<\/h2>\n\n\n\n