Picture the machine: a $5-a-month VPS with 2 GB of RAM running a web app, a database, and a monitoring agent — or a ten-year-old laptop that is perfectly fine except when it isn't. No swap configured, because "SSD swap is slow" and "I'll just add RAM later." Then a traffic spike or a browser tab too many arrives, and the OOM killer starts choosing which of your processes gets to live. It never chooses well.

There is a third option between "no swap" and "slow disk swap," and it costs exactly nothing: zram.

What zram actually does

zram creates compressed block devices that live in RAM itself, and you use one as swap. When the kernel needs to page out idle memory, instead of writing those pages to disk, it compresses them and keeps them in a reserved slice of RAM. Swappable pages — idle application memory, file caches nobody is touching — typically compress at 2:1 to 3:1, so a 1 GB zram device effectively holds 2–3 GB of paged-out data while costing a fraction of that in real RAM.

The result: swapping stops being a trip to disk and becomes a quick compress/decompress round-trip in memory. On a small VPS without any swap partition, or a laptop with a slow drive, the difference between "the OOM killer murdered my database" and "things got briefly sluggish, then recovered" is often just this.

One paragraph on the cousin: zswap is a compressed cache that sits in front of an existing disk swap device — it needs that disk swap to exist. zram is a standalone swap device made of compressed RAM — no disk involved at all. If your VPS has no swap partition (most cheap ones don't), zram is the one you want.

The 15-minute setup

The modern way to configure zram is zram-generator, a small systemd helper. Install it from your distro's repositories:

# Arch / CachyOS
sudo pacman -S zram-generator

# Fedora
sudo dnf install zram-generator

# Debian 12+ / Ubuntu
sudo apt install systemd-zram-generator

Then create one config file:

# /etc/systemd/zram-generator.conf
[zram0]
zram-size = ram / 2
compression-algorithm = zstd

That's the whole configuration. A [zram0] section is all the generator needs — without a config file it won't create anything, but the defaults are sane: if you omit zram-size, it uses half your RAM capped at 4 GB. zstd is the default compressor and the right choice on any modern CPU; it's fast enough that the compression cost is noise next to a disk seek.

Activate it:

sudo systemctl daemon-reload
sudo systemctl start /dev/zram0

From the next boot on, systemd sets it up automatically. Verify it's working:

$ swapon --show
NAME       TYPE      SIZE USED PRIO
/dev/zram0 partition 3.9G   0B  100

$ zramctl
NAME       ALGORITHM DISKSIZE  DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 zstd          3.9G    0B    0B    0B       8 [SWAP]

DATA is the uncompressed size of what's stored, COMPR is what it actually costs you in RAM. Watch those two columns over a week — the ratio between them is your real-world compression, and it's the number that tells you whether the setup is earning its keep.

The tuning that makes it work

Two knobs matter.

Size. Half your RAM is the sane default, and the 4 GB cap exists because beyond that you're usually just shuffling deck chairs. On a 2 GB VPS, a 1 GB zram device is plenty. On a 16 GB desktop, you could go bigger, but ask yourself what you're actually protecting against — zram is a safety net for spikes, not a substitute for RAM you genuinely need.

Swappiness. This is the one people get backwards. The default vm.swappiness=60 was tuned for an era when swap meant a spinning disk and swapping was a punishment. With zram, the swap target is fast — so you want the kernel to use it eagerly, paging out idle anonymous memory to keep more RAM free for caches and active work. Values in the 100–180 range are common with zram setups:

# /etc/sysctl.d/99-zram.conf
vm.swappiness = 180

Apply with sudo sysctl --system. If that number makes you nervous, start at 100 and watch free -h and vmstat 1 under load for a few days. The behavior you're looking for: under pressure, swap usage climbs smoothly instead of the system falling off a cliff into OOM-killer territory.

To see exactly what zram is doing at any moment, the kernel exports detailed stats:

cat /sys/block/zram0/mm_stat

The columns tell you original vs. compressed sizes, same-page deduplication, and more — the raw material for deciding whether your sizing is right.

When it can't save you

Honesty section. zram cannot create RAM; it can only make the RAM you have work harder. If your workload genuinely needs 8 GB resident and you have 2 GB, no compression ratio fixes that — you'll just thrash inside the compressor instead of on disk. Workloads with incompressible data (encrypted buffers, already-compressed media, some ML inference) get little benefit, and on a CPU-starved single-vCore VPS the compression itself can become the bottleneck under extreme pressure.

What zram is for: absorbing spikes, surviving the OOM killer, and making small machines behave like slightly bigger ones. That covers an enormous fraction of real-world "my VPS is slow" complaints.

Fifteen minutes, one config file, zero dollars. The cheapest RAM upgrade you'll ever install is the one made of math.

Sources: zram-generator on GitHub (configuration format, install commands, and defaults verified against the project README) · zram: Compressed RAM-based block devices — Linux kernel documentation · kernel.org zram docs (docs.kernel.org)