Swap on a VPS is either treated as untouchable folklore or configured on autopilot \u2014 a 2 GB swapfile because that is what a tutorial once said. Both approaches ignore the actual mechanics. Swap is not a performance feature; it is a safety valve that trades disk latency for the ability to survive a memory spike. Whether that trade is a good deal depends entirely on your storage medium, your workload’s access patterns, and how the kernel’s page-reclaim heuristics behave under pressure.<\/p>\n\n\n\n
The kernel moves pages to swap for two different reasons, and conflating them causes most of the bad advice. First, anonymous pages that have been idle can be evicted to make room for page cache \u2014 this is cheap and often improves throughput. Second, under genuine memory pressure the kernel is forced to swap out active working sets, and that is what produces the infamous multi-second stalls. You want the first behaviour and want to avoid the second. A well-tuned server rarely faults pages back in from swap except at startup after a reboot.<\/p>\n\n\n\n
The traditional “2x RAM” rule was written for systems with 512 MB of memory and spinning disks. On a modern instance the useful sizing question is: how much headroom do I need to absorb a spike while an operator intervenes? For a 1 GB instance running a web stack, 1\u20132 GB of swap is plenty; more just delays the inevitable OOM kill while thrashing the disk. For a 4 GB database host, 2\u20134 GB is a reasonable emergency reserve. If you are unsure how much memory your workload genuinely needs, this guide to VPS plans and resource allocation<\/a> is a better starting point than guessing at swap size.<\/p>\n\n\n\n Verify the current configuration before changing anything:<\/p>\n\n\n\n A swapfile on the same filesystem as your data is the simplest option but shares I\/O with everything else. A zram device compresses pages in RAM, giving you effective capacity at zero disk latency \u2014 excellent for small instances where the alternative is OOM penalties, but it consumes CPU and does nothing if the compressed data would not fit. A dedicated swap partition avoids filesystem fragmentation issues but is inflexible. On most VPS workloads a modest swapfile plus a small zram device covers both the “survive the spike” and “cheap eviction” cases.<\/p>\n\n\n\nswapon --show; free -m; cat \/proc\/sys\/vm\/swappiness; vmstat 1 5<\/code><\/pre>\n\n\n\nThe
vm.swappiness<\/code> Question<\/h2>\n\n\n\nvm.swappiness<\/code> controls the relative cost the kernel assigns to reclaiming page cache versus swapping anonymous pages. It is not a simple on\/off dial. On an NVMe-backed instance a value of 10\u201320 keeps the kernel biased toward cache eviction while still allowing swap under real pressure. Setting it to 0 does not disable swapping \u2014 it only discourages it until the situation is dire, at which point reclaim becomes more aggressive and the stall is worse, not better. Measure the effect rather than copying a number: watch vmstat<\/code> columns si<\/code> and so<\/code> during a realistic load.<\/p>\n\n\n\nSwapfile vs zram vs a Dedicated Partition<\/h2>\n\n\n\n
Measuring Whether Swap Is Helping or Hurting<\/h2>\n\n\n\n