🧠 Tuning Linux Swap and zram for Better Memory Performance

“Just turn off swap, it’s faster” is one of the most persistent pieces of bad advice in Linux administration. I’ve inherited plenty of servers with swapoff baked into provisioning, and they don’t run faster — they run fine until they suddenly die, because the moment memory runs out the OOM killer reaps a process at random instead of the kernel gently paging out something idle. Swap done right isn’t a crutch for being out of RAM; it’s a pressure-relief valve that turns a hard crash into graceful slowdown. Let’s tune it properly, including the modern trick: zram.

What swap actually does

The kernel keeps hot pages in RAM and can move cold ones — memory a process allocated but hasn’t touched in a while — out to swap. This frees RAM for things that are actually being used, like filesystem cache. On a healthy server with swap, you’ll often see a few hundred MB swapped out even with free RAM, and that’s correct: those are genuinely cold pages and evicting them made room for useful cache.

The pathological case people fear — constant paging that grinds the disk, aka thrashing — happens when the working set exceeds RAM, not because swap exists. The fix for that is more RAM or less load, not swapoff.

Sizing and creating swap

A swap file is easier to resize than a partition and works fine on modern kernels:

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

How much? For servers, “a fraction of RAM” beats the old “2x RAM” rule. On a 32GB box, 4–8GB of swap is plenty to absorb cold pages without enabling a runaway. You’re providing a buffer, not a second tier of RAM.

swappiness: the knob people get wrong

vm.swappiness (0–100, default usually 60) controls how aggressively the kernel prefers swapping anonymous memory versus reclaiming file cache. Contrary to popular belief, it is not a percentage of RAM and setting it to 0 does not disable swap.

# Check current value
cat /proc/sys/vm/swappiness
# Set for a database / latency-sensitive server: prefer keeping cache, swap less
sudo sysctl vm.swappiness=10
# Persist it
echo 'vm.swappiness=10' | sudo tee /etc/sysctl.d/99-swap.conf

My defaults: 10 for database and latency-sensitive workloads where you want to protect the page cache, 60 (the default) for general-purpose servers, and higher when using zram (more on that below). Don’t set it to 0 thinking it helps — you just disabled the graceful-degradation behavior you wanted.

zram: compressed swap in RAM

Here’s the modern move. zram creates a block device backed by RAM that compresses whatever you write to it. Used as swap, it gives you a fast, compressed overflow tier — paging to “disk” that’s actually still in memory, just squeezed. On memory-bound boxes it’s a genuine win: typical 2–3x compression means cold pages take a third of the space, and access is RAM-fast instead of disk-slow.

sudo modprobe zram
# Pick a compression algorithm
echo zstd | sudo tee /sys/block/zram0/comp_algorithm
# Size it — this is the *uncompressed* capacity
echo 4G | sudo tee /sys/block/zram0/disksize
sudo mkswap /dev/zram0
sudo swapon --priority 100 /dev/zram0

The --priority 100 is the trick: the kernel fills higher-priority swap first, so cold pages go to fast compressed RAM (zram) before ever touching a low-priority disk swapfile. You get a tiered swap hierarchy automatically.

Most distros ship zram-generator or systemd-zram-setup to make this persistent and properly sized — prefer that over hand-rolled modprobe in production:

sudo apt install systemd-zram-generator   # or distro equivalent
# Configure in /etc/systemd/zram-generator.conf

With zram in play, raise swappiness (say 100) — you actively want the kernel to use this fast tier.

Watch it, don’t guess

free -h               # used/free/swap at a glance
swapon --show         # all swap devices and their priorities
cat /sys/block/zram0/mm_stat   # zram: original vs compressed bytes (your real ratio)
vmstat 1              # si/so columns = swap in/out per second

The si/so columns in vmstat are the ones that matter: a few KB occasionally is healthy; sustained high so under load means your working set genuinely exceeds RAM and no tuning will save you — you need more memory or less work.

Where AI helps

The hard part of memory tuning is interpreting the numbers, not setting the knobs. I paste free -h, vmstat 1 output, and the zram mm_stat into a model and ask “is this host under real memory pressure or just using swap correctly?” The distinction between healthy cold-page eviction and actual thrashing is exactly the judgment call a model is good at helping with — it reads the si/so rates and the compression ratio and tells me which it is. Keep a few Linux performance prompts for this and you stop misreading a healthy server as a sick one.

The bottom line

Don’t disable swap — configure it. Add a modestly-sized swapfile, set swappiness to match the workload, and add zram as a fast compressed tier with higher priority than disk swap. Then watch vmstat to tell graceful paging apart from real pressure. Done right, memory pressure becomes a gentle slowdown you have time to react to, instead of a process getting OOM-killed at the worst possible moment. More tuning guides live in the AI for Linux Admins series.

Memory tuning interacts with your specific workload. Measure with vmstat and free before and after changes rather than applying values blindly.