Debian 13 : ZRAM/Zswap — quand ça sauve votre machine et quand ça se retourne contre vous

Modèle mental : ce que font réellement zram et zswap

ZRAM : un périphérique bloc compressé en RAM

ZRAM crée un périphérique bloc en mémoire (comme /dev/zram0) et laisse le noyau le traiter comme un dispositif de swap.
Quand le noyau décide d’expulser une page, cette page peut atterrir dans zram, compressée.
Le « disque » est de la mémoire, mais vous gagnez en capacité effective parce que les pages sont compressées. Vous payez en cycles CPU.

Pensez à zram comme à un « swap sans stockage », ce qui sonne paradoxal jusqu’à ce que vous vous rappeliez : les pages sont souvent compressibles (remplies de zéros, données répétitives, vieux déchets du heap, JSON mis en cache qu’on n’aurait pas dû garder, etc.).
En cas de crise, compresser 4 GiB de pages froides en 2 GiB de RAM est un gain. Compresser 4 GiB en 3,9 GiB n’est qu’une manière coûteuse d’être déçu.

Zswap : un cache compressé devant un vrai backend de swap

Zswap est différent. Ce n’est pas un périphérique de swap. C’est un cache pour les pages swapées, stockées compressées en RAM, placé devant votre swap réel (partition ou fichier de swap).
Quand des pages sont swapées, zswap essaie de les garder compressées en mémoire. Si le pool zswap se remplit, il évince des pages vers le vrai périphérique de swap.

Cela fait de zswap un « réducteur d’écritures » et lisse la latence : moins d’écritures sur SSD/HDD, moins d’E/S aléatoire en pression, meilleures latences extrêmes quand le système thrash.
Mais il dépend toujours d’un backend de swap correct. Pas de périphérique de swap, pas de filet de sécurité zswap.

La différence opérationnelle qui compte

• zram peut remplacer le swap disque sur de petits systèmes, ou devenir le « niveau de swap rapide » devant le disque si vous conservez aussi le swap disque.
• zswap est un cache ; il réduit les E/S de swap mais ne remplace pas la capacité de swap.
• Les deux sont des formes d’échange CPU contre mémoire. Sur les CPU modernes, ce pari est souvent gagnant. Sur des systèmes chargés, il peut être désastreux.

Une idée paraphrasée souvent attribuée à Jim Gray : « Mesurez avant de tunner ; la plupart des réglages sont de la conjecture sans données. » (idée paraphrasée)
La compression mémoire en est un parfait exemple. Il est facile d’être astucieux. Il est plus difficile d’avoir raison.

Blague #1 : La compression mémoire, c’est comme passer vos vêtements sous vide. Ça marche super bien jusqu’à ce que vous ayez besoin de cette chemise lors d’un exercice d’évacuation.

Contexte et faits : comment on en est arrivé là (et pourquoi ça compte)

Un peu de contexte transforme le « bidouillage aléatoire de noyau » en ingénierie réelle. Voici quelques faits concrets à garder en tête :

1. zram a commencé comme « ramzswap » il y a des années, puis a été renommé et upstreamé ; l’idée a toujours été « swap compressé en RAM », pas un cache général.
2. zswap est arrivé comme backend frontswap, ce qui signifie qu’il s’accroche au sous-système de swap comme couche de cache plutôt que périphérique bloc.
3. Les algorithmes de compression ont changé la donne : LZO était populaire pour la vitesse ; LZ4 est devenu courant ; ZSTD a gagné en traction pour de meilleurs ratios à coût acceptable.
4. La comptabilité mémoire de Linux s’est durcie au fil du temps (cgroups v2, PSI, meilleur comportement de reclaim), rendant « ça paraît plus lent » diagnostiquable avec de vrais signaux.
5. Chrome et navigateurs modernes ont rendu le swap normal à nouveau sur postes : grands ensembles de travail avec beaucoup d’onglets froids, souvent compressibles par endroits.
6. Les SSD ont rendu le swap viable mais pas gratuit : la latence est bonne comparée aux disques rotatifs, mais les écritures aléatoires soutenues sous pression tuent toujours les latences extrêmes et peuvent amplifier l’usure.
7. Les conteneurs ont rendu le swap politique : certaines organisations interdisent le swap pour les nœuds, d’autres y dépendent ; la compression mémoire devient un compromis quand vous voulez de la grâce sans vous mentir.
8. Les valeurs par défaut du noyau sont conservatrices : la plupart des distributions évitent des valeurs agressives pour zram/zswap parce qu’un mauvais défaut devient un cauchemar de support.
9. La force de Debian est la prévisibilité, d’où le fait que vous devez souvent opter pour des choses sophistiquées — et pourquoi vous devez tester sérieusement quand vous le faites.

Quand zram/zswap sauve votre machine (et quand ce n’est pas le cas)

Utilisez zram quand : vous avez besoin de « quelques Mo de swap » mais le stockage est lent, fragile ou absent

zram brille sur :

• Petites VM où le stockage de l’hyperviseur est bruyant ou thin-provisioned et où les E/S de swap causent des problèmes au niveau du cluster.
• Boîtiers edge avec flash bon marché où l’usure du swap est une vraie préoccupation.
• Ordinateurs portables de développeurs avec pressions mémoire par rafales : builds, navigateurs, IDE et « j’ai oublié mon Docker ».
• Systèmes avec beaucoup de marge CPU et pression mémoire modérée : le coût de la compression reste maîtrisé.

Ce que vous achetez : la capacité d’éviter les OOM dans des pressions faibles à modérées et une réduction de l’usure du swap disque.
Ce que vous n’achetez pas : de la mémoire infinie. Si votre ensemble de travail dépasse réellement la RAM de beaucoup, zram ne fait que changer la manière dont vous échouez.

Utilisez zswap quand : vous voulez garder un vrai swap, mais le rendre moins pénible

zswap brille quand vous avez déjà du swap sur SSD/NVMe (ou même HDD) et que vous voulez lisser le pire comportement sous reclaim :

• Bases de données et JVM où même de petites latences de swap-in peuvent créer des queues de latence, mais vous voulez quand même une soupape de décharge.
• Hôtes de VM où les tempêtes d’E/S de swap causent de la contention sur le stockage ; zswap réduit l’amplification d’écriture.
• Charges mixtes où « certaines pages sont froides et compressibles » est vrai, mais vous ne pouvez pas prévoir lesquelles.

Ne tentez pas quand : le goulot d’étranglement n’est pas la pression mémoire

Si vous êtes déjà limité par le CPU, ajouter de la compression revient à engager un comptable pendant un incendie de cuisine parce qu’il est « doué avec les nombres ».
Si vous êtes I/O-bound à cause d’autres charges disque, zswap peut aider en réduisant les E/S de swap — mais il ne corrigera pas la contention disque sous-jacente.

Vérité dure : la compression ne remplace pas la planification de capacité

zram/zswap sont d’excellents outils de « dégradation contrôlée ». Ils ne vous donnent pas licence pour exécuter 28 GiB de services sur une VM 16 GiB.
Si votre ensemble de travail en régime permanent est plus grand que la RAM, la solution correcte est plus de RAM, moins de charge, ou les deux.
La compression peut vous acheter du temps. Rarement la tranquillité.

Comment ça se retourne contre vous : modes de défaillance qui ressemblent à « Linux est lent »

Retour de bâton #1 : saturation CPU due à la compression

Le mode de défaillance le plus courant est simple : le système subit une pression mémoire, il commence à swapper, et maintenant il compresse/décompresse.
Si vos CPU sont déjà occupés, ce travail supplémentaire vous pousse dans une spirale mortelle : moins de CPU pour l’application, plus de stalls, plus d’arriérés, plus de churn mémoire.

Cela arrive souvent avec :

• des nœuds web chargés avec allocations par requête et forte pression GC,
• des runners CI effectuant beaucoup de builds parallèles,
• n’importe quelle machine où vous avez essayé de « réparer la mémoire » en activant ZSTD à un niveau élevé sans mesurer.

Retour de bâton #2 : faux sentiment de stabilité (« on a arrêté les OOM ») suivi d’un effondrement de latence

zram en particulier peut transformer un OOM immédiat en une longue période de misère.
Le système ne meurt pas. Il devient simplement inutilisable : pics de latence interactive, timeouts RPC, resets de watchdog, et l’astreinte apprend de nouveaux jurons.

Sur les serveurs, la bonne question n’est pas « avons-nous évité l’OOM ? » mais « avons-nous préservé les SLO ? »
Parfois tuer un processus rapidement est plus bienveillant que de garder tout à moitié vivant pendant 20 minutes.

Retour de bâton #3 : le reclaim se bat contre votre charge

L’activité de swap n’est pas intrinsèquement mauvaise, mais le reclaim agressif peut l’être.
Si l’ensemble chaud de votre charge est large et en déplacement constant (par ex. caches qui churn, jobs d’analytics, ou métriques haute cardinalité), le noyau peut évincer des pages dont vous aurez besoin bientôt.
Avec zram/zswap, vous payez maintenant un surcoût pour un cycle « compresser, stocker, décompresser, refaire un fault ».

Retour de bâton #4 : pools mal dimensionnés et surprises de « priorité de swap »

Vous pouvez exécuter swap disque et zram ensemble. Le noyau choisit en fonction de la priorité de swap.
Si vous vous trompez, vous pouvez accidentellement envoyer des pages sur le disque en premier, laissant zram mostly idle tandis que votre SSD hurle.
Ou à l’inverse : vous pouvez remplir zram trop agressivement, laissant trop peu de RAM réelle pour le page cache et les ensembles chauds applicatifs.

Retour de bâton #5 : pool zswap plein + backend lent = falaise soudaine

zswap a l’air génial jusqu’à ce que le pool soit plein. Ensuite il doit évincer vers le backend swap réel.
Si ce backend est lent ou en contention, vous passez de « agréable » à « oh non » rapidement.
Ce n’est pas que zswap a cassé ; c’est que vous viviez sur de la latence empruntée.

Blague #2 : Activer la compression de swap sans mesurer, c’est comme installer un turbo sur un chariot élévateur. Ça va plus vite jusqu’à ce qu’il rencontre la physique.

Playbook de diagnostic rapide (premières/deuxièmes/troisièmes vérifications)

Quand une machine Debian 13 est « lente » et que vous suspectez une pression mémoire, ne commencez pas par éditer des knobs sysctl.
Commencez par répondre à trois questions : Sommes‑nous sous pression mémoire ? Swapp‑ons‑nous ? La douleur vient‑elle du CPU ou de l’I/O ?

Premièrement : confirmer la pression et qui la cause

• Vérifier PSI (pressure stall information) : les tâches sont‑elles bloquées sur le reclaim mémoire ?
• Vérifier les fautes majeures et les swap-ins : faisons‑nous du paging actif ?
• Identifier les plus gros consommateurs RSS/anon et s’ils augmentent.

Deuxièmement : déterminer si la compression aide ou nuit

• Profil CPU en un coup d’œil : est‑ce que kswapd est chaud ? kcompactd tourne‑t‑il ? Brûle‑t‑on du CPU dans les chemins de compression ?
• Statistiques zram : quel est le remplissage, le ratio de compression, les débits lecture/écriture ?
• Statistiques zswap : taille du pool, pages stockées, compteurs reject/duplicate, et évictions vers le disque.

Troisièmement : choisir la mitigation la moins mauvaise

• Si le système thrash : réduire la concurrence, réduire la charge, arrêter les jobs batch, ou redémarrer temporairement le pire consommateur mémoire.
• Si le backend de swap est le goulot : activer/ajuster zswap ou ajouter un petit niveau zram avec la bonne priorité.
• Si le CPU est le goulot : baisser le coût de compression (choix d’algorithme), ou désactiver la compression et accepter un OOM plus rapide.

Tâches pratiques : commandes, sorties et décisions (12+)

Ces commandes sont prévues pour être lancées sur un hôte Debian 13 réel. Chaque tâche inclut : une commande, ce que signifie la sortie, et la décision que vous pouvez prendre.
Rien de magique ici. Juste de l’observation disciplinée.

Task 1: Verify whether zram devices exist and are used

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,ROTA,MOUNTPOINTS
NAME        TYPE  SIZE ROTA MOUNTPOINTS
vda         disk   80G    1
├─vda1      part   79G    1 /
└─vda2      part    1G    1 [SWAP]
zram0       disk    8G    0

Signification : zram0 est présent et apparaît comme un disque. La taille est la taille virtuelle configurée.
Le swap disque est vda2.

Décision : Si vous attendez zram mais que vous ne le voyez pas, vous ne l’utilisez pas. Si vous le voyez mais qu’il est minuscule/énorme, validez le dimensionnement.

Task 2: Check active swap devices and priorities

cr0x@server:~$ swapon --show=NAME,TYPE,SIZE,USED,PRIO
NAME      TYPE      SIZE   USED PRIO
/dev/zram0 partition   8G   512M  100
/dev/vda2 partition    1G     0B   -2

Signification : zram a une priorité plus élevée (100) donc il sera utilisé avant /dev/vda2.

Décision : Si votre swap disque a une priorité plus élevée que zram, corrigez‑le sauf si vous avez une raison délibérée.

Task 3: Measure overall memory and swap pressure quickly

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            15Gi        12Gi       320Mi       1.1Gi       2.9Gi       1.2Gi
Swap:           9.0Gi       1.0Gi       8.0Gi

Signification : « available » est le chiffre clé pour la marge à court terme. L’utilisation du swap indique que nous avons commencé à évincer.

Décision : Si available est faible et que le swap augmente, vous êtes en territoire de reclaim. Passez à PSI et vmstat ensuite.

Task 4: Check memory PSI to see if the kernel is stalling tasks

cr0x@server:~$ cat /proc/pressure/memory
some avg10=0.42 avg60=0.30 avg300=0.18 total=43832490
full avg10=0.07 avg60=0.05 avg300=0.02 total=8203491

Signification : « some » montre la contention de reclaim ; « full » indique des stalls sévères où les tâches ne progressent pas à cause de la pression mémoire.

Décision : Si « full avg10 » est non négligeable pour un service sensible à la latence, vous êtes passé de la phase de « réglage » à celle de la mitigation : réduire la charge, tuer les coupables, ajouter de la RAM.

Task 5: Watch swap-in/out and reclaim behavior live

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  1  942080 332000  60200 812000  120  240    14    90  820 1280 40 10 35 15  0
 1  2  954368 318000  60180 810500  200  420     0   140  900 1400 45 12 28 15  0
 3  1  990720 290000  60150 808900  320  500     0   210 1050 1600 52 13 20 15  0
 2  2 1015808 270000  60120 807400  410  690     0   260 1120 1750 55 15 16 14  0
 2  1 1048576 250000  60090 805100  300  520     0   180  980 1500 50 13 22 15  0

Signification : si/so sont les swap-ins/outs par seconde. Des valeurs non nulles soutenues suggèrent du paging actif.
Le wa CPU indique l’attente I/O ; s’il monte pendant le swapping, le backend swap peut être pénible.

Décision : Un si élevé suggère que vous payez le coût maintenant (faults de retour). Un so élevé suggère que vous poussez des pages hors de la RAM. Dans les deux cas, trouvez le hog mémoire et décidez : tuer/redémarrer/throtter.

Task 6: Determine if the box is slow due to disk swap IO

cr0x@server:~$ iostat -xz 1 3
Linux 6.12.0 (server)  12/30/2025  _x86_64_  (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          45.12    0.00    9.20   18.44    0.00   27.24

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz  aqu-sz  %util
vda              2.00     48.00     0.00   0.00   3.50    24.00  120.00   4096.00     0.00   0.00  45.00    34.13    5.40  98.00

Signification : Une utilisation proche de 100 % et un await élevé sur le périphérique backend de swap signifient que votre stockage est un goulot.

Décision : Si le disque est saturé pendant le swapping, zswap peut aider. S’il est déjà activé et que c’est toujours saturé, le backend est trop lent ou le système est sur‑engagé.

Task 7: Inspect zram compression ratio and current usage

cr0x@server:~$ cat /sys/block/zram0/mm_stat
786432000 196608000 131072 0 0 0 0 0

Signification : Les champs varient selon le noyau, mais incluent typiquement : taille des données originales, taille compressée, et métadonnées.
Ici, ~750 Mo de pages originales compressées en ~187 Mo : un bon ratio.

Décision : Si la taille compressée est proche de la taille originale, zram vous apporte peu ; envisagez un algorithme plus rapide, un zram plus petit, ou la désactivation si le CPU souffre.

Task 8: Check which algorithm zram uses

cr0x@server:~$ cat /sys/block/zram0/comp_algorithm
lzo [lz4] zstd

Signification : L’algorithme entre crochets est actif (lz4).

Décision : Pour les serveurs, préférez lz4 pour la vitesse sauf si vous avez prouvé que ZSTD améliore suffisamment le ratio pour réduire significativement le paging.

Task 9: Verify whether zswap is enabled and what it’s doing

cr0x@server:~$ cat /sys/module/zswap/parameters/enabled
Y

cr0x@server:~$ grep -H . /sys/kernel/debug/zswap/*
/sys/kernel/debug/zswap/pool_total_size: 268435456
/sys/kernel/debug/zswap/stored_pages: 23144
/sys/kernel/debug/zswap/same_filled_pages: 120
/sys/kernel/debug/zswap/duplicate_entry: 340
/sys/kernel/debug/zswap/reject_reclaim_fail: 0
/sys/kernel/debug/zswap/reject_compress_poor: 42
/sys/kernel/debug/zswap/written_back_pages: 1800

Signification : zswap est activé. Il stocke des pages dans le pool, en rejette certaines pour compression insuffisante, et en renvoie certaines sur disque.

Décision : Un taux élevé de written_back_pages combiné à un disque lent suggère que le pool est trop petit, la pression mémoire trop élevée, ou que le backend swap est le vrai problème.

Task 10: Confirm the kernel swap policy knobs (swappiness and friends)

cr0x@server:~$ sysctl vm.swappiness vm.vfs_cache_pressure vm.page-cluster
vm.swappiness = 60
vm.vfs_cache_pressure = 100
vm.page-cluster = 3

Signification : swappiness influence la propension du noyau à swapper vs reclaim du page cache. page-cluster affecte les schémas de ré‑lecture lors du swap.

Décision : Si vous exécutez un swap zram‑only sur une machine sensible à la latence, envisagez de baisser swappiness (souvent 10–30) pour éviter de swapper trop vite des pages anonymes. Mesurez après.

Task 11: Identify top memory consumers (RSS/anon) without fooling yourself

cr0x@server:~$ ps -eo pid,comm,rss,%mem --sort=-rss | head -n 10
  PID COMMAND           RSS %MEM
 2210 java          4123456 26.1
 1842 postgres      2104320 13.3
 3011 node          1456896  9.2
 1123 prometheus     802560  5.1

Signification : RSS est la resident set size : ce qui est actuellement en RAM. Sous pression, le RSS peut chuter pendant que les performances s’effondrent parce que le processus fault des pages en entrée/sortie.

Décision : Si un processus est énorme et continue de croître, soit vous le limitez (quotas), le réglez (heap, caches), soit vous le traitez comme un incident. Ne « rajoutez pas juste du zram » pour éviter la conversation.

Task 12: Check major page faults to confirm real paging pain

cr0x@server:~$ pidstat -r 1 3
Linux 6.12.0 (server)  12/30/2025  _x86_64_  (8 CPU)

12:20:01 PM   UID       PID  minflt/s  majflt/s     VSZ     RSS   %MEM  Command
12:20:02 PM  1000      2210   2300.00     12.00 6123456 4123456  26.1  java
12:20:02 PM  1000      1842    820.00      6.00 3256780 2104320  13.3  postgres
12:20:03 PM  1000      2210   2500.00     20.00 6123456 4123456  26.1  java

Signification : Les fautes majeures (majflt/s) nécessitent un accès disque ou swap (ou au moins un chemin de fault non trivial). Si les fautes majeures augmentent avec les pics de latence, vous swappez en colère.

Décision : Si les fautes majeures sont soutenues, concentrez‑vous sur la réduction de l’ensemble de travail et du churn de swap. La compression peut aider si elle réduit les E/S disque ; elle ne résoudra pas une charge surdimensionnée.

Task 13: Confirm cgroup v2 memory limits (container hosts love to lie)

cr0x@server:~$ cat /sys/fs/cgroup/memory.max
max

cr0x@server:~$ cat /sys/fs/cgroup/memory.current
12582912000

Signification : Pas de limite cgroup à la racine ; l’usage courant est ~11.7GiB. Pour les conteneurs/services, vérifiez leurs cgroups individuels aussi.

Décision : Si un service a une limite trop serrée, il peut thrash à l’intérieur de son cgroup même si l’hôte a de la mémoire. Corrigez la limite avant de tuner le swap.

Task 14: Check zram activity rates via /proc/swaps and /proc/vmstat

cr0x@server:~$ cat /proc/swaps
Filename				Type		Size		Used		Priority
/dev/zram0                               partition	8388604		524288		100
/dev/vda2                                partition	1048572		0		-2

cr0x@server:~$ egrep 'pswpin|pswpout' /proc/vmstat
pswpin 184233
pswpout 392001

Signification : Les compteurs totaux de swap-in/out vous permettent de corréler les « périodes lentes » avec le paging.

Décision : Si pswpin augmente pendant les incidents, vous payez la latence du swap. Si seul pswpout augmente, vous poussez des pages dehors (peut‑être proactivement à cause de swappiness).

Conseils de réglage : les réglages importants sous Debian 13

Choisissez votre stratégie : zram‑only, zswap‑only, ou une configuration en niveaux

Voici le point de vue production :

• zram‑only : bon pour les petits systèmes et appareils edge où le swap disque est inacceptable. Risque : thrash prolongé plutôt qu’un OOM rapide.
• zswap‑only : meilleur choix général quand vous avez déjà du swap sur SSD/NVMe. Il réduit les E/S sans faire semblant que la RAM est infinie.
• niveaué (zram + swap disque) : puissant si vous réglez correctement les priorités. zram absorbe le churn ; le swap disque est le dernier recours.

Choix d’algorithme : ne soyez pas trop malin avant d’être stable

Pour zram et zswap, le choix d’algorithme est une décision de politique :

• LZ4 : rapide, ratio correcte, généralement le choix par défaut le plus sûr pour les serveurs.
• LZO : aussi rapide, parfois un peu moins bon que LZ4 en ratio.
• ZSTD : meilleur ratio, coût CPU supérieur ; peut être excellent si cela évite les E/S disque, désastreux si le CPU est déjà serré.

Ma règle : si vous diagnostiquez un incident, choisissez la vitesse. Si vous concevez une configuration stable sur une machine riche en CPU, expérimentez ZSTD — mais mesurez PSI « full » et la latence tail.

Dimensionner zram : arrêtez de le traiter comme de la RAM gratuite

Les conseils de dimensionnement zram circulent comme de la médecine populaire (25 %, 50 %, « égal à la RAM », etc.).
En production, la taille de zram dépend de ce que vous voulez que le système survive, pas de ce que vous voulez qu’il feigne d’être.

• Sur serveurs : commencez autour de 10–25 % de la RAM si vous l’utilisez comme niveau rapide, pas comme béquille de capacité.
• Sur laptops/desktops : 25–50 % de la RAM est souvent raisonnable parce que les charges interactives en bénéficient et vous pouvez tolérer un peu de coût CPU.
• Sur systèmes minuscules (≤ 2–4 GiB RAM) : zram peut être proportionnellement plus grand, mais attention : le CPU de petits cœurs peut devenir le goulot.

Dimensionnement zswap : contrôler le pool et le comportement d’éviction

Le pool de zswap a un pourcentage maximal de RAM et il utilise un allocateu r (souvent zbud/z3fold) qui échange densité contre CPU et fragmentation.
Si le pool est trop petit, vous réécrivez vite sur disque et perdez l’intérêt. Trop grand, et vous déplacez le page cache et les pages anonymes chaudes.

Un démarrage raisonnable pour des serveurs avec swap SSD est souvent une limite de pool dans la plage 10–20 % RAM.
Si vous atteignez fréquemment l’écriture de retour en charge normale, vous êtes sous‑dimens ionné ou votre charge est assez en rafales pour revoir limites et concurrence.

Swappiness : on ne gagne pas un débat politique avec un seul entier

vm.swappiness n’est pas « combien de swap je veux ». C’est une partie d’un système de décision sur le reclaim du page cache vs la mémoire anonyme.
Avec zswap, une swappiness plus élevée peut être acceptable parce que les swap-outs peuvent rester en RAM compressée, réduisant les E/S. Avec zram‑only, une swappiness trop haute peut causer du churn inutile.

Règle pratique :

• Serveurs sensibles à la latence : commencez autour de 10–30 et testez.
• Machines polyvalentes : les valeurs par défaut (60) peuvent convenir, surtout avec zswap.
• Services heavy cache : vous pourriez vouloir une valeur plus élevée si le reclaim du page cache est souhaitable, mais seulement si vous comprenez les compromis.

Ce que les admins Debian 13 devraient standardiser

Standardisez deux choses sur vos flottes :

1. Visibilité : exporter PSI (/proc/pressure/*), swap-in/out (/proc/vmstat), et stats zram/zswap. Si vous ne pouvez pas voir, vous blâmerez « Linux ».
2. Politique : décidez par classe de nœud si le swap est permis et s’il s’agit de zswap, zram, ou des deux. La cohérence bat l’astuce à 3 h du matin.

Trois micro-récits d’entreprise depuis le terrain

Micro-récit 1 : l’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne exploitait une flotte de VM Debian pour des APIs internes. L’équipe plateforme a activé zswap sur les nouvelles images.
L’hypothèse était propre : « zswap signifie que le swap est désormais bon marché, on peut arrêter de s’inquiéter des tempêtes de swap. »
Ils ont aussi réduit silencieusement la taille du swap à « juste au cas où », parce qu’ils ne voulaient pas que l’usage disque surprenne quelqu’un.

Des mois plus tard, un déploiement de routine a augmenté l’utilisation mémoire de quelques centaines de mégaoctets par instance.
Rien de dramatique. Aucun processus unique n’est devenu fou. Le type d’accroissement lent qui fait ressembler les graphiques à de douces collines.
Sous pic de charge, les nœuds ont commencé à timeout. Pas de crash — des timeouts. Les retries ont augmenté, ce qui a augmenté la charge, ce qui a augmenté le churn mémoire. Classique.

L’astreinte a trouvé zswap activé et sain. Le pool s’est rempli, puis a commencé à écrire vers le swap backend.
Mais le backend swap était minuscule, donc il s’est rempli rapidement aussi. Une fois le swap plein, le noyau a moins d’options ; vous obtenez pression de reclaim, stalls, et finalement OOM — souvent au pire moment.
Le système n’avait pas un grand filet de swap ; il avait un piège de petit swap.

La correction fut ennuyeuse : restaurer une taille de swap backend raisonnable, garder zswap, et alerter sur la saturation du pool zswap et le taux de croissance d’utilisation du swap.
L’équipe a aussi ajouté une vérification de « budget mémoire » aux déploiements : de petites augmentations par nœud peuvent devenir de grands schémas de panne au niveau de la flotte.

Micro-récit 2 : l’optimisation qui a échoué

Une autre organisation exploitait des runners CI sous Debian. Les builds étaient fortement parallélisés, et la pression mémoire était attendue.
Quelqu’un a lu que ZSTD avait de meilleurs ratios de compression et a décidé d’« améliorer les performances » en passant zram à ZSTD partout.
Le changement avait l’air super dans un test calme : l’usage du swap a baissé, et la « mémoire libre » semblait meilleure.

En production, le CPU était la vraie ressource rare. Ces runners étaient déjà occupés à compiler, linker, compresser des artefacts, et effectuer des handshakes crypto avec des registries.
Quand la pression mémoire est arrivée, le système a commencé à compresser les pages avec ZSTD. Le CPU est passé de « occupé mais correct » à « saturé et chaotique ».
Les temps de build ont augmenté. Les temps de file d’attente ont augmenté. Les ingénieurs ont ajouté plus de jobs parallèles pour compenser, ce qui a empiré la situation.

L’indice était dans des métriques qu’ils ne regardaient pas : PSI mémoire « full » a monté pendant les heures de pointe, et le steal CPU sur l’hyperviseur a augmenté alors que tout le monde se battait pour les cycles.
Le « meilleur ratio de compression » était sans importance ; le système n’avait pas besoin de plus de capacité de swap efficace. Il avait besoin de moins de surcharge CPU sous contention.

Ils sont revenus à LZ4, ont réduit légèrement la taille du zram, et ont ajouté une politique d’ordonnancement pour limiter les builds concurrents en fonction de la mémoire disponible et des seuils PSI.
Résultat net : moins de tours de magie noyau, meilleur débit, et moins de lenteurs mystérieuses.

Micro-récit 3 : la pratique ennuyeuse mais correcte qui a sauvé la mise

Un service adjacent aux paiements (toujours amusant) tournait sur Debian avec un budget de latence strict. L’équipe SRE avait une politique : le swap est autorisé, mais seulement avec zswap, et seulement avec des alertes spécifiques.
Ils suivaient PSI mémoire, taux de swap-in, et temps d’attente disque. Rien de fancy. Juste de la visibilité cohérente.

Un après‑midi, une montée de trafic est arrivée en même temps qu’un changement de configuration anodin qui a augmenté le caching en mémoire.
L’utilisation mémoire a monté, et le reclaim a démarré. La clé était que le système n’est pas immédiatement tombé ; zswap a absorbé les premiers swap-outs, réduisant les écritures disque.
Mais les alertes se sont déclenchées : PSI mémoire « full » a légèrement augmenté, et les pages écrites par zswap ont commencé à augmenter — un avertissement précoce que le pool se remplissait.

L’astreinte n’a pas deviné. Ils ont suivi le runbook : réduire la taille du cache, baisser la concurrence des workers, et scaler horizontalement.
Pas de redémarrages spectaculaires. Pas de « on va essayer zram aussi ». Juste une mitigation contrôlée en restant dans les SLO.
L’incident est devenu une non‑événement : un ticket, une action, et une correction avant que les clients ne s’en aperçoivent.

La pratique qui les a sauvés était banale : ils avaient des indicateurs avancés. L’utilisation du swap est un indicateur retardé ; quand elle est énorme, vous payez déjà.
PSI et l’écriture de retour zswap leur ont donné une chance d’agir avant que la machine ne devienne un diaporama.

Erreurs courantes : symptômes → cause racine → correctif

1) Symptom: load average is high, CPU is high, but nothing “seems” busy

Cause racine : des threads noyau brûlent du CPU à faire du reclaim et de la compression de pages (kswapd, workqueues de compression), souvent déclenchés par zram/zswap sous pression.

Fix : confirmer avec PSI et vmstat. Si le CPU est la contrainte, passez à un algorithme plus rapide (LZ4), réduisez zram, baissez la concurrence, ou désactivez temporairement la compression pour forcer un OOM plus rapide et une reprise.

2) Symptom: disks hit 100% util during “memory incidents”

Cause racine : le backend swap subit de lourdes écritures/lectures ; zswap peut être désactivé, mal configuré, ou trop petit ; la priorité de zram peut être incorrecte.

Fix : activer zswap (avec un vrai périphérique de swap), s’assurer que zram (si utilisé) a une priorité supérieure au disque, et vérifier que le swap disque n’est pas sur un périphérique en contention.

3) Symptom: “We enabled zram, now caches are worse and performance regressed”

Cause racine : zram trop grand ; il vole de la RAM au page cache et aux pages anonymes chaudes, causant plus d’E/S et de fautes.

Fix : réduire la taille du zram ; traitez‑le comme un petit tampon d’urgence, pas comme une seconde banque de RAM. Retestez avec la charge réelle.

4) Symptom: system doesn’t OOM anymore, but becomes unresponsive for minutes

Cause racine : thrash : l’ensemble de travail dépasse significativement la RAM. zram rend l’échec plus lent et plus douloureux.

Fix : définir des limites, réduire l’usage mémoire, ou ajouter de la RAM. Envisagez de garder un petit swap disque avec zswap (ou pas de swap) selon les SLO ; décidez si un OOM rapide est préférable à de longues interruptions.

5) Symptom: zswap enabled, but swap writes still heavy

Cause racine : le pool zswap se sature rapidement ; mauvais ratios de compression (beaucoup de rejects) ; ou le backend swap est utilisé directement à cause de la politique/priorité.

Fix : inspecter les compteurs debug de zswap ; augmenter modestement le plafond du pool ou ajuster l’algorithme ; vérifier les périphériques et priorités de swap ; corriger la croissance mémoire sous‑jacente.

6) Symptom: container workloads OOM inside cgroups even though host has free memory

Cause racine : cgroup memory.max trop bas ; le comportement de swap diffère à l’intérieur du cgroup ; le zram/zswap au niveau hôte ne corrigera pas une mauvaise limite.

Fix : ajuster les limites cgroup, définir des budgets par service, et monitorer le PSI par cgroup si possible. N’utilisez pas la compression swap système comme pansement pour de mauvais quotas.

7) Symptom: “Swap is used even when RAM is available”

Cause racine : incompréhension des rapports mémoire Linux ; « available » vs « free », dynamique du page cache, et reclaim proactif.

Fix : utilisez free -h et concentrez‑vous sur « available », utilisez PSI pour confirmer la pression réelle. Ne désactivez pas le swap à chaud parce que « swap utilisé != mauvais ».

8) Symptom: suspend/resume or hibernate issues on laptops after enabling zram

Cause racine : l’hibernation nécessite un backing store de swap assez grand pour écrire l’image RAM ; zram n’est pas adapté comme seul target d’hibernation.

Fix : conservez une partition/fichier de swap disque dimensionné pour l’hibernation ; utilisez zram comme swap additionnel avec priorité plus élevée, pas comme seul swap.

Listes de vérification / plan pas à pas

Checklist A: Decide what to deploy (per node class)

1. Classer le nœud : laptop, VM, base de données, runner CI, hôte de conteneurs, edge box.
2. Définir la préférence d’échec : OOM rapide vs ralentissement gracieux. Pour les services critiques en latence, un échec rapide est souvent plus sûr.
3. Vérifier la marge CPU : si le CPU est régulièrement >70 % en pointe, le coût de la compression peut nuire.
4. Vérifier la qualité du backend swap : SSD/NVMe ok ; stockage réseau lent ou disques en contention non.
5. Choisir une stratégie : zswap‑only pour la plupart des serveurs ; zram‑only pour edge sans disque lent ; niveaué pour environnements avec stockage bruyant.

Checklist B: Safe baseline for a Debian 13 server (zswap-first)

1. Assurez‑vous d’avoir un vrai périphérique de swap (fichier ou partition) dimensionné selon votre politique.
2. Activez zswap et commencez avec un algorithme rapide.
3. Configurez des alertes sur PSI mémoire « full » et le taux de swap‑in.
4. Faites un test de charge avec une concurrence réaliste et surveillez la latence tail, pas seulement le débit.
5. Ensuite seulement, envisagez d’ajouter un petit niveau zram si le swap disque reste le goulot.

Checklist C: Tiered swap (zram + disk) without self-sabotage

1. Créer/activer un swap zram avec une priorité supérieure au swap disque.
2. Conserver le swap disque comme filet de secours avec priorité inférieure.
3. Limiter la taille de zram à une fraction conservatrice (10–25 % RAM pour serveurs).
4. Utiliser LZ4 sauf preuve mesurée du contraire.
5. Monitorer : remplissage zram, ratio de compression, taux swap‑in/out, et CPU.

Checklist D: Incident response when memory pressure hits

1. Vérifier PSI (mémoire). Si « full » est élevé, traitez‑le comme une sévérité.
2. Vérifier le taux de swap‑in et les fautes majeures. Confirmer le paging actif.
3. Vérifier l’attente/util disque. Si le disque est saturé, l’I/O fait partie du problème.
4. Trouver le plus gros coupable et décider : redémarrer, limiter, ou scaler.
5. Post‑incident : corriger la régression mémoire et ajouter un garde‑fou (limite, budget, ou alerte).

FAQ

1) Should I use zram or zswap on Debian 13?

Pour la plupart des serveurs : zswap avec un vrai backend de swap. Pour petits dispositifs/edge : zram peut être excellent. Pour stockage bruyant : une configuration en niveaux peut être excellente si les priorités sont correctes.

2) Can I run both zram and zswap together?

Oui, mais soyez délibéré. zswap met en cache les pages destinées aux dispositifs de swap ; si un de ces périphériques de swap est zram, vous pouvez vous retrouver à compresser « devant » un périphérique déjà compressé. Cela peut être une surcharge redondante.
Le schéma niveaué courant est zram + swap disque, pas zswap + zram, sauf si vous avez mesuré un réel bénéfice.

3) Does swap compression prevent the OOM killer?

Elle peut retarder l’OOM en augmentant la capacité effective pour les pages froides/compressibles. Elle n’élimine pas l’OOM si l’ensemble de travail continue de croître.
Parfois retarder l’OOM est mauvais : vous obtenez des minutes de timeouts au lieu d’un échec rapide et d’un redémarrage.

4) What compression algorithm should I choose?

Commencez par LZ4 pour les serveurs. Envisagez ZSTD seulement après avoir mesuré la marge CPU et prouvé que le meilleur ratio réduit suffisamment le swap disque pour améliorer la latence tail.

5) What’s a sane zram size?

Serveurs : souvent 10–25 % de la RAM quand utilisé comme niveau rapide. Desktops : 25–50 % peut fonctionner.
Si vous le dimensionnez « égal à la RAM » et que vous vous arrêtez là, vous construisez un générateur de panne en temps ralenti.

6) Why is swap being used when there is “free” memory?

Parce que « free » n’est pas « available », et Linux utilise la mémoire pour les caches de manière agressive. De plus, le noyau peut swapper des pages anonymes froides pour préserver le cache.
Regardez « available » dans free -h et utilisez PSI pour confirmer les stalls réels.

7) How do I know if zswap is actually helping?

Cherchez une réduction des taux d’écriture disque sous pression mémoire, une baisse du I/O wait, et des latences tail stables. Dans les stats zswap, vous voulez un nombre sain de pages stockées et des taux d’écriture de retour maîtrisables.
Si le pool se sature et que les written-back pages explosent, vous ne faites que reporter la douleur disque.

8) Is swap bad for databases like PostgreSQL?

Le swap non planifié est mauvais pour les bases sensibles à la latence. Mais une petite quantité de swap avec zswap peut prévenir un OOM catastrophique et réduire les tempêtes d’E/S.
La vraie solution est un dimensionnement mémoire correct et éviter l’overcommit ; zswap est une ceinture de sécurité, pas un nouveau moteur.

9) Will zram reduce SSD wear?

Oui, si cela remplace ou réduit les écritures de swap sur disque. zswap aide aussi en absorbant les swap-outs en RAM et en écrivant moins en retour.
Mais si vous thrashiez fort, vous écrirez encore sur disque (évictions zswap) et vous consommerez aussi du CPU.

10) Why did enabling zram make the system slower even without heavy swapping?

Si zram est surdimensionné, il consomme de la RAM pour ses propres métadonnées et concurrence le page cache. Le système peut reclaimer plus agressivement ou avoir un taux de cache hit moindre, causant plus d’I/O.
Dimensionnez‑le prudemment et vérifiez avec des tests de charge réels.

Conclusion : prochaines étapes réalisables aujourd’hui

Si vous exploitez Debian 13 en production, traitez zram/zswap comme n’importe quelle autre fonctionnalité de performance : optez‑y volontairement, mesurez en continu, et revenez en arrière quand ça vous ment.
La bonne nouvelle est que vous n’avez pas besoin d’héroïsme. Vous avez besoin d’un plan.

1. Choisir une politique par défaut par classe de nœud (zswap‑only est la victoire ennuyeuse pour beaucoup de serveurs).
2. Ajouter de la visibilité : PSI mémoire, swap-in/out, attente disque/util, et stats zram/zswap.
3. Lancer un test de pression qui reflète la réalité : concurrence maximale, jobs de fond, et voisins bruyants inclus.
4. Définir votre préférence d’échec : OOM rapide vs thrash lent, et aligner les réglages de swap/compression sur celle‑ci.
5. Corriger la cause racine après l’incident : budgets mémoire, limites, et dimensionnement. La compression n’est pas un plan de capacité.

Le noyau fera de son mieux pour garder votre système vivant. Votre travail est de faire en sorte que « vivant » signifie encore « utile ».