TL;DR / Summary: Swap is not extra RAM, and sizing it with a copied internet rule usually makes a small VPS slower. Base the size on your actual RAM and workload, tune swappiness gently, and learn to read vmstat so you can tell normal cold-page eviction from the disk-thrashing spiral.
What swap does and does not fix
Swap lets the kernel move inactive pages out of memory and bring them back when needed. It buys headroom for occasional spikes, such as a backup job or a package upgrade, and it prevents the out-of-memory killer from ending a process during a brief surge.
It does not make the machine faster. Every swapped page that is touched again has to come back from disk, and on a shared VPS that disk may be a network volume with latency measured in milliseconds rather than microseconds.
The honest framing is that swap is insurance. It is cheap to add, occasionally decisive, and actively harmful when the system relies on it continuously instead of using it for short-term overflow.
Choosing a size from RAM, not folklore
The old “twice your RAM” rule was written for machines with 256 MB of memory and hard drives that idled for milliseconds. On a 2 GB VPS the same rule produces 4 GB of swap that will almost never be used well.
A more practical starting point is one to two gigabytes for a small web server, scaled to the largest process you expect to spike. If your database can grow to 900 MB, swap should at least cover the gap between that and your RAM ceiling.
Also consider hibernation, which needs swap proportional to RAM, though almost no VPS user enables it. If you do not hibernate, that constraint disappears and the size can stay modest.
A worked example: a 2 GB VPS running a web app at roughly 600 MB, a database at 500 MB, and a caching layer at 300 MB leaves about 600 MB of headroom. A 1 GB swap file covers a package upgrade or a backup spike without ever becoming a permanent home for the database.
swappiness values that suit a web server
The swappiness setting controls how eagerly the kernel reclaims anonymous pages. A value of 60, common on desktop systems, tends to swap too readily for a server that would rather drop file cache.
Values between 10 and 30 are a reasonable range for a small web server. Lower values keep application memory resident and let the page cache shrink first, which is usually the right trade when disk is slow.
Do not set it to zero unless you understand the consequences. Zero does not disable swap; it makes the kernel avoid it until memory pressure is severe, which can produce a sudden and dramatic stall instead of a gradual slowdown.
Recognizing thrashing in vmstat output
Run vmstat with a short interval and watch the si and so columns, which report pages swapped in and out per second. Small occasional values are normal. Sustained nonzero values alongside high wa, the IO wait percentage, mean the disk is now part of your critical path.
Cross-check with free, which shows the swap used column. A slowly rising figure during idle periods suggests a leak or an oversized cache; a figure that climbs during every request suggests the working set simply does not fit.
The most telling signal is latency. If response times triple while CPU sits idle, the machine is waiting on swap, and no amount of application tuning will fix it.
Swap on NVMe versus network storage
Local NVMe makes swap tolerable because random reads are fast. A network-attached volume makes swap much worse, since every page fault becomes a round trip, and the latency is not under your control.
Check what your provider actually provisions. Some advertise SSD storage that is local, while others mount a shared volume over the network. The difference is invisible in the panel and very visible in vmstat.
If your swap lives on network storage, keep the size small and treat the machine as RAM-bound. Adding swap there is like adding a longer straw to a short drink.
When adding RAM beats tuning swap
If swap usage stays high after a week of normal traffic, the workload needs memory, not tuning. Upgrading from 2 GB to 4 GB is often a one-click change at the provider and cheaper than the engineering time spent shaving fifty megabytes off a service.
Before upgrading, confirm the pressure is real. A large page cache is not a problem; Linux uses free memory for caching and gives it back on demand. Only anonymous memory pressure that forces swapping counts.
For a plan comparison while you decide, the VPS plans page shows how the RAM tiers and prices line up, which makes the cost of headroom concrete.
Setting up swap without hurting the disk
Create a swap file rather than a partition, so you can resize it later without repartitioning. Set permissions to root-only, enable it, and add the entry to fstab so it survives a reboot.
Then leave it alone for a week and collect data before changing anything else. Tuning swap on the same day you provision a server is guesswork, and guesswork tends to be remembered as configuration.
The goal is a machine that never notices its swap file. If you do notice it, the fix is almost always memory, not a cleverer sysctl value.
