Con RAM sempre più costosa rispetto allo storage NVMe e con i workload containerizzati che spremono ogni gigabyte disponibile, la gestione dello swap è tornata centrale per chi amministra server Linux, desktop e persino dispositivi embedded. Da anni il kernel offre due meccanismi di compressione della memoria molto diversi tra loro — zram e zswap — che vengono spesso confusi o usati in modo intercambiabile. In realtà risolvono problemi diversi, hanno comportamenti opposti sotto pressione di memoria e, se configurati male o combinati tra loro, possono peggiorare le prestazioni invece di migliorarle. Vediamo come funzionano, quando scegliere l’uno o l’altro e come configurarli correttamente, con i parametri sysfs e i sysctl che contano davvero in produzione.

zram: un dispositivo di swap interamente in RAM

zram crea un blocco a dimensione fissa (/dev/zram0, /dev/zram1…) che vive interamente in RAM e comprime ogni pagina che vi viene scritta. Non serve alcuno storage reale: il dispositivo può essere usato come area di swap con mkswap e swapon, oppure formattato come filesystem (ext4, XFS) per directory temporanee come /tmp o /var/cache.

Il punto chiave è che zram occupa memoria solo in proporzione a quanto viene effettivamente compresso: se il rapporto di compressione è 2:1, un dispositivo da 4 GB userà al massimo 2 GB di RAM reale quando è pieno. Ma proprio perché ha una dimensione fissa, una volta saturo il kernel deve trovare un’altra destinazione per le pagine in eccesso — da qui la raccomandazione, di cui parliamo più avanti, di non affidarsi a zram come unica rete di sicurezza su sistemi critici.

zswap: una cache compressa davanti allo swap reale

zswap parte da un presupposto diverso: non è un dispositivo di swap, ma una cache compressa che si frappone tra la memoria e un dispositivo di swap reale su disco o SSD. Quando il kernel deve scartare una pagina, zswap prova prima a comprimerla e tenerla nel suo pool; solo le pagine “fredde” (poco usate) vengono alla fine scritte sul device di swap sottostante, e solo le pagine che si comprimono bene restano nel pool — quelle incomprimibili vengono scartate e mandate direttamente al backing device.

Questo rende il pool di zswap dinamico: cresce sotto pressione di memoria e si restringe quando il sistema è tranquillo, invece di occupare uno spazio fisso come zram. Lo svantaggio è che zswap richiede comunque un dispositivo di swap reale configurato: senza quello, non ha dove scaricare le pagine fredde. Nella serie di patch “Virtual Swap Space”, ancora non mergiata nel kernel mainline, si lavora proprio per rimuovere questo vincolo, ma ad oggi resta un prerequisito.

Le differenze tecniche in sintesi

Quando scegliere l’uno o l’altro

La regola pratica, confermata anche da discussioni recenti nella comunità Linux, è semplice: nel dubbio, usa zswap, mantenendo comunque un file di swap su disco dietro di esso. zram resta la scelta giusta in casi più specifici:

• Sistemi senza alcun dispositivo di swap, come board embedded, Raspberry Pi o VM diskless.
• Storage molto lento, dove anche l’I/O occasionale verso lo swap reale è inaccettabile.
• Workload desktop con pattern di memoria prevedibili, dove un limite fisso è accettabile.

Per server con container o servizi limitati via cgroup, invece, zram è generalmente sconsigliato: la memoria che occupa non viene conteggiata nei limiti di memoria del cgroup, il che falsa la contabilità delle risorse e può portare un container a superare silenziosamente il proprio budget di RAM. In questi scenari zswap è la scelta più sicura, perché la gestione dell’eviction resta all’interno del normale meccanismo di reclaim del kernel.

Un avvertimento importante: non combinare zram e un device di swap su disco contemporaneamente. Mischiare i due crea quella che viene chiamata inversione della LRU (LRU inversion), in cui pagine “calde” appena swappate finiscono sul disco lento mentre pagine più fredde restano nel device veloce in RAM — un pattern che degrada le prestazioni invece di migliorarle. Se si usa zram, deve essere l’unico dispositivo di swap attivo.

Configurare zswap: boot parameter e tuning a runtime

Il modo più comune per abilitare zswap all’avvio è tramite i parametri del kernel, aggiunti alla riga GRUB_CMDLINE_LINUX in /etc/default/grub e seguiti da update-grub (o grub2-mkconfig):

zswap.enabled=1 zswap.compressor=lzo zswap.max_pool_percent=25

Oltre al boot time, molti di questi parametri sono regolabili anche a runtime tramite sysfs, utile per sperimentare senza riavviare:

# Stato e compressore
cat /sys/module/zswap/parameters/enabled
echo 1 > /sys/module/zswap/parameters/enabled
echo lzo > /sys/module/zswap/parameters/compressor

# Percentuale massima di RAM dedicabile al pool compresso
echo 25 > /sys/module/zswap/parameters/max_pool_percent

# Shrinker: libera pagine fredde dal pool invece di lasciarle accumulare
echo Y > /sys/module/zswap/parameters/shrinker_enabled

# Soglia di accettazione: 100 disabilita l'isteresi di scarico
echo 80 > /sys/module/zswap/parameters/accept_threshold_percent

A partire dal kernel 6.8 è possibile anche disattivare il writeback di zswap per singolo cgroup, utile per impedire che un container specifico scarichi pagine sul disco di swap condiviso:

echo 0 > /sys/fs/cgroup/<nome-cgroup>/memory.zswap.writeback

Configurare zram: dal modulo al servizio systemd

Per un setup manuale, il flusso di base è: caricare il modulo, scegliere l’algoritmo, impostare la dimensione e attivare lo swap.

# Carica il modulo e crea i device
modprobe zram num_devices=1

# Seleziona l'algoritmo di compressione (va fatto prima di inizializzare il device)
echo zstd > /sys/block/zram0/comp_algorithm

# Imposta la dimensione (operazione che inizializza il device)
echo 2G > /sys/block/zram0/disksize

# Attiva come swap, con priorità alta rispetto allo swap su disco
mkswap /dev/zram0
swapon -p 100 /dev/zram0

In produzione è più comodo affidarsi a zram-tools (o systemd-zram-generator sulle distribuzioni più recenti), che gestisce la creazione del device a ogni boot. Un file /etc/default/zramswap tipico:

PERCENT=25
ALGO=zstd
PRIORITY=32000

seguito da systemctl restart zramswap (o il nome del servizio corrispondente sulla propria distribuzione) per applicare la configurazione.

Per verificare le statistiche di compressione in tempo reale, il device espone un file mm_stat con i contatori principali (byte originali, byte compressi, memoria totale allocata inclusi gli overhead):

cat /sys/block/zram0/mm_stat
zramctl
swapon --show
free -h

Dimensionare correttamente lo swap compresso

Un errore comune è sovradimensionare zram pensando che “più grande è meglio”. Non è così: zram compete per la stessa RAM fisica che sta cercando di risparmiare. La linea guida pratica è mantenere il device zram tra il 20% e il 30% della RAM fisica, senza mai arrivare al 50%. Su una macchina con 16 GB di RAM, ad esempio, un device zram da circa 4 GB offre un buon compromesso: con un rapporto di compressione di 2:1 (tipico di LZO), occuperà al massimo 2 GB quando saturo, estendendo la capacità di lavoro utile del sistema di circa 18 GB totali prima di dover ricorrere allo swap su disco (se presente) o rischiare l’OOM.

Per zswap, il parametro equivalente è max_pool_percent: un valore del 20% su un sistema con 16 GB di RAM corrisponde a un pool massimo di circa 3,2 GB, capace di assorbire picchi di memoria più ampi proprio perché il pool è dinamico e non sottrae RAM quando non serve.

La scelta dell’algoritmo di compressione è anch’essa un compromesso tra CPU e rapporto di compressione: LZ4 è il più veloce ma comprime meno (circa 1,5:1), LZO è un buon compromesso (circa 2:1) ed è spesso la scelta di default, mentre Zstd offre i rapporti migliori (fino a 3:1 e oltre) a fronte di un costo CPU maggiore — scelta sensata su CPU moderne con diversi core disponibili.

Il rischio dell’OOM silenzioso

Uno dei problemi meno discussi di zram è il suo comportamento quando il device si satura senza uno swap su disco di riserva: il sistema può restare bloccato per diversi minuti con il kernel che tenta disperatamente di liberare memoria, senza che l’OOM killer intervenga in tempo utile. Non è un caso isolato: Cloudflare ha documentato pubblicamente episodi di “brownout” di 20-30 minuti proprio legati a questo pattern, in cui l’OOM killer del kernel non si attivava abbastanza rapidamente. La raccomandazione pratica è eseguire sempre un OOM daemon in userspace — systemd-oomd (incluso di default in molte distribuzioni moderne) o earlyoom — su qualunque sistema che faccia uso di zram, in modo da terminare proattivamente i processi più pesanti prima che il kernel arrivi allo stallo.

Conclusione

zram e zswap non sono intercambiabili: risolvono problemi diversi e vanno scelti in base al contesto. Su server con container, cgroup e storage veloce, zswap è oggi la scelta più sicura e prevedibile, perché si integra correttamente con la contabilità della memoria dei cgroup e degrada in modo più controllato sotto pressione. zram resta prezioso per sistemi senza swap su disco o con storage molto lento — ma va dimensionato con prudenza, mai mescolato con uno swap reale, e sempre accompagnato da un OOM daemon in userspace. In entrambi i casi, monitorare regolarmente l’uso dello swap con strumenti come free -h e zramctl resta il modo più semplice per capire se è il caso di aggiungere RAM fisica invece di continuare a ottimizzare la compressione.

Fonte: I was wrong! zswap IS better than zram, LinuxBlog.io. Documentazione tecnica: kernel.org — zswap e kernel.org — zram.