On a VPS you cannot add physical RAM, so when memory pressure arrives you have two broad escapes: spill to disk-backed swap, or compress cold pages in RAM with zram. They behave nothing alike. Disk swap trades latency for capacity; zram trades CPU time for capacity without ever touching the disk. Choosing wrong produces either thrashing databases or burned CPU cycles. This article measures both and gives a decision rule.<\/p>\n\n\n\n
A swap partition or file pages anonymous memory out to block storage. Every subsequent access is a page fault that must read from disk \u2014 on a shared NVMe VPS this is tens to hundreds of microseconds latency, and on a throttled volume it can be milliseconds. Sequential throughput may look fine while random fault latency destroys tail response times.<\/p>\n\n\n\n
zram creates a compressed block device backed entirely by RAM. Pages written to it are compressed with LZ4 or zstd and stay in memory. A page fault triggers decompression, which costs CPU cycles but no disk I\/O. Typical compression ratios of 2:1 to 4:1 mean 1 GB of zram can hold 2-4 GB of logical data.<\/p>\n\n\n\n
# Debian\/Ubuntu\napt install -y zram-tools\n\n# size to roughly 50-100% of RAM, LZ4 for speed\ncat >\/etc\/default\/zramswap <<'EOF'\nALGO=lz4\nPERCENT=75\nPRIORITY=100\nEOF\n\nsystemctl restart zramswap\nswapon --show\nzramctl<\/code><\/pre>\n\n\n\nThe PRIORITY<\/code> matters: give zram a higher priority than any disk swap so the kernel prefers the compressed device, and keep disk swap as a last-resort safety net rather than the first line of defence.<\/p>\n\n\n\nMeasuring the difference<\/h2>\n\n\n\n
Create controlled memory pressure and watch both the fault rate and the CPU cost. Using stress-ng<\/code> with a memory worker bounded above available RAM forces the kernel to reclaim:<\/p>\n\n\n\n# watch fault behaviour and CPU sys time\nvmstat 1 30 &\nstress-ng --vm 1 --vm-bytes 90% --vm-hang 0 --timeout 60s\n\n# per-process swap usage\nfor f in \/proc\/*\/status; do \\\n awk '\/^Name|^VmSwap\/{printf \"%s \", $2}' $f; echo; \\\n done | sort -k3 -n | tail -10<\/code><\/pre>\n\n\n\nMetric<\/th> Disk swap<\/th> zram (LZ4)<\/th><\/tr><\/thead> Fault latency<\/td> 100 us – 5 ms<\/td> 5-50 us<\/td><\/tr> CPU cost<\/td> minimal<\/td> notable (sys time up)<\/td><\/tr> Effective capacity<\/td> full disk size<\/td> 2-4x RAM allocation<\/td><\/tr> Risk<\/td> I\/O thrash, TTFB spikes<\/td> CPU saturation, OOM at high ratio<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nWhen zram is the wrong answer<\/h2>\n\n\n\n- CPU-bound workloads.<\/strong> If your single vCPU already sits near 100%, adding compression work makes everything slower. Check with
mpstat -P ALL 1<\/code> first.<\/li>- Working sets that genuinely exceed 4x RAM.<\/strong> Compression cannot manufacture capacity; past a point you OOM just as hard, only later and with more CPU burned.<\/li>
- Databases with large page caches.<\/strong> A MySQL or PostgreSQL instance whose hot set is disk-resident gains little from compressing anonymous memory and may delay the honest signal that it needs more RAM.<\/li><\/ul>\n\n\n\n
When disk swap is the wrong answer<\/h2>\n\n\n\n