Swap vs zRAM on a VPS: Which Improves Performance Under Memory Pressure?

When a Linux VPS runs out of RAM, the kernel has two tools for buying time: disk-backed swap and zRAM. Both prevent the OOM killer from terminating your processes, but they behave very differently under memory pressure — one trades speed for capacity, the other compresses data in RAM itself. Choosing between them (or combining them) is one of the highest-impact memory decisions you can make on a small VPS, so it is worth understanding the mechanics precisely.

How Disk Swap Works

A traditional swap file or partition lives on disk. When the kernel needs RAM for active pages, it writes cold pages out to the swap device. The advantage is capacity: you can create 4 GB of swap on a 2 GB VPS and never run out of addressable memory again. The disadvantage is latency: even on NVMe storage, swapping a page costs tens of microseconds at best, and under heavy pressure the disk becomes a bottleneck that drags the whole system down. Worse, on shared hosting infrastructure your swap I/O competes with every other tenant’s disk traffic.

How zRAM Works

zRAM creates a compressed block device in RAM itself. When the kernel swaps to it, pages are compressed with LZ4 or ZSTD instead of being written to disk. The math is simple: typical server memory compresses at 2.5–3.5x, so a 1 GB zRAM device holds roughly 2.5–3.5 GB of pages. The swap operation is a few microseconds of CPU work instead of a disk write — orders of magnitude faster — and there is zero disk I/O involved.

The trade-off is that zRAM does not add capacity — it just makes existing RAM go further. And it costs CPU: every page swapped to zRAM must be compressed on the way in and decompressed on the way out. On a single-vCPU VPS, heavy swapping to zRAM can consume 10–20% of your CPU. On multi-core servers with idle cores, that cost is usually invisible. If your VPS plan’s CPU is already oversubscribed by the host, that overhead matters more — compare CPU allocation policies across providers on our comparison table before choosing where to run memory-hungry workloads.

zRAM vs Swap: Direct Comparison

Property	Disk swap	zRAM
Effective capacity	Full swap size	Swap size × compression ratio
Latency per swap	Microseconds–milliseconds (disk-bound)	Microseconds (CPU-bound)
CPU cost	Negligible	Compression/decompression overhead
Survives reboot	Yes (persistent)	No (RAM-resident)
Disk I/O under pressure	High	None
Best for	Crash safety, large overflow	Latency-sensitive interactive workloads

Setting Up zRAM on Ubuntu/Debian

On modern Ubuntu and Debian systems, zRAM is one command away:

apt install zram-tools
# configure in /etc/default/zramswap
# ALGO=zstd
# PERCENT=50
systemctl enable --now zramswap

With PERCENT=50, a 2 GB VPS gets a 1 GB zRAM device. Verify it with zramctl, which shows the compressed size versus the original size — the ratio tells you how well your workload compresses. Logs, JSON payloads, and text-heavy data compress extremely well; already-compressed data (images, video, encrypted files) compresses poorly and gains little from zRAM.

Combining zRAM and Disk Swap

For most VPS workloads, the best configuration is both, with priorities set so the kernel fills zRAM first and only touches disk swap when zRAM is exhausted. Set vm.swappiness=100 (not 10 — the usual advice for disk swap) when zRAM is your primary swap, because swapping to zRAM is cheap and frees compressible RAM for the page cache. Give zRAM a higher priority than the disk swap device:

swapon /dev/zram0 -p 100
swapon /swapfile -p 10

This gives you the latency benefits of zRAM under normal pressure and the capacity of disk swap as a safety net when memory demand spikes hard. The kernel only touches the disk after the compressed device fills — exactly the behavior you want on a budget VPS.

When to Avoid zRAM

• CPU-bound single-core workloads — if your process already pegs the CPU, zRAM’s compression cost makes memory pressure worse.
• Already-compressed data — media servers, backup targets, and encrypted filesystems gain almost nothing.
• Kernel crash dumps — zRAM is RAM-resident; a kernel panic loses everything in it. Disk swap preserves crash dumps.
• Huge incompressible datasets — if your working set genuinely exceeds RAM and compresses poorly, only disk swap (or more RAM) saves you.

Before making any change, establish a baseline. Run your workload under controlled load with free -h, vmstat 1, and zramctl (once enabled), and record swap-in/swap-out rates. After switching, compare the same metrics — swap I/O should drop to zero with zRAM, and if your latency-sensitive metric (request p99, query time) improves, the change is working. For a full memory-management picture, our guide to VPS memory tuning covers swap, OOM killer behavior, and the related kernel parameters in one place.

One more consideration: memory configuration interacts with the rest of the system. If you are also tuning kernel parameters, the sysctl settings for swapping, the OOM killer, and the page cache all need to be consistent — a mismatch (for example, swappiness=10 with a zRAM-only setup) quietly defeats the whole configuration. And if you are shopping for a VPS specifically because you keep hitting memory ceilings, compare VPS providers on our comparison table — a 4 GB plan often costs less than the engineering time spent squeezing a 2 GB one, and InterServer’s budget VPS lineup is a reasonable place to compare.

Summary

zRAM wins on latency and disk I/O; disk swap wins on capacity and persistence. On a VPS under memory pressure, the pragmatic answer is usually both: zRAM at high priority for speed, a modest disk swap as a capacity backstop, with swappiness tuned to match. Measure first, change one variable at a time, and confirm the improvement with swap counters — memory tuning is only as good as the data you use to validate it.