{"id":763,"date":"2026-08-01T02:57:01","date_gmt":"2026-08-01T02:57:01","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=763"},"modified":"2026-08-01T02:57:01","modified_gmt":"2026-08-01T02:57:01","slug":"vps-swap-vs-zram-performance","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/vps-swap-vs-zram-performance\/","title":{"rendered":"Swap vs zRAM on a VPS: Which Improves Performance Under Memory Pressure?"},"content":{"rendered":"\n

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 \u2014 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.<\/p>\n\n\n\n

How Disk Swap Works<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

How zRAM Works<\/h2>\n\n\n\n

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\u20133.5x, so a 1 GB zRAM device holds roughly 2.5\u20133.5 GB of pages. The swap operation is a few microseconds of CPU work instead of a disk write \u2014 orders of magnitude faster \u2014 and there is zero disk I\/O involved.<\/p>\n\n\n\n

The trade-off is that zRAM does not add capacity \u2014 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\u201320% 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 \u2014 compare CPU allocation policies across providers on our comparison table<\/a> before choosing where to run memory-hungry workloads.<\/p>\n\n\n\n

zRAM vs Swap: Direct Comparison<\/h2>\n\n\n\n
Property<\/th>Disk swap<\/th>zRAM<\/th><\/tr><\/thead>
Effective capacity<\/td>Full swap size<\/td>Swap size \u00d7 compression ratio<\/td><\/tr>
Latency per swap<\/td>Microseconds\u2013milliseconds (disk-bound)<\/td>Microseconds (CPU-bound)<\/td><\/tr>
CPU cost<\/td>Negligible<\/td>Compression\/decompression overhead<\/td><\/tr>
Survives reboot<\/td>Yes (persistent)<\/td>No (RAM-resident)<\/td><\/tr>
Disk I\/O under pressure<\/td>High<\/td>None<\/td><\/tr>
Best for<\/td>Crash safety, large overflow<\/td>Latency-sensitive interactive workloads<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Setting Up zRAM on Ubuntu\/Debian<\/h2>\n\n\n\n

On modern Ubuntu and Debian systems, zRAM is one command away:<\/p>\n\n\n\n

apt install zram-tools\n# configure in \/etc\/default\/zramswap\n# ALGO=zstd\n# PERCENT=50\nsystemctl enable --now zramswap<\/code><\/pre>\n\n\n\n
With PERCENT=50<\/code>, a 2 GB VPS gets a 1 GB zRAM device. Verify it with zramctl<\/code>, which shows the compressed size versus the original size \u2014 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.<\/p>\n\n\n\n
Combining zRAM and Disk Swap<\/h2>\n\n\n\n
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<\/code> (not 10 \u2014 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:<\/p>\n\n\n\n
swapon \/dev\/zram0 -p 100\nswapon \/swapfile -p 10<\/code><\/pre>\n\n\n\n
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 \u2014 exactly the behavior you want on a budget VPS.<\/p>\n\n\n\n
When to Avoid zRAM<\/h2>\n\n\n\n