Proxmox : la swap ne cesse de croître — comprendre la pression mémoire et la stabiliser

Procédure de diagnostic rapide

Si vous n’avez que 10 minutes avant que quelqu’un ne propose « ajoutez juste de la RAM », faites ceci dans l’ordre. Vous essayez de répondre à une question :
la croissance de la swap est-elle due à une vraie pression, à un reclaim mal configuré ou à un tableau de bord menteur ?

1) Confirmer que le symptôme est réel (et pas juste une panique sur la mémoire mise en cache)

• Vérifiez la swap utilisée sur l’hôte et le débit d’E/S de swap (pas seulement « swap utilisée »).
• Vérifiez la pression mémoire (PSI) et l’activité de kswapd.

2) Identifier la source de la pression

• Est-ce que ZFS ARC grignote l’espace libre ?
• Avez-vous sur-alloué la RAM entre les VM ou les conteneurs ?
• Le ballooning force-t-il les clients à descendre et pousse-t-il l’hôte dans un chaos de reclaim ?

3) Déterminer le stabilisateur

• Si la pression est soutenue : réduisez les engagements (mémoire des VM), limitez l’ARC ou ajoutez de la RAM.
• Si le reclaim est pathologique : corrigez swappiness, watermark, et les interactions hugepages/THP ; ajoutez zram si approprié.
• Si la swap est « utilisée mais calme » : envisagez de la laisser, ou de drainer la swap de manière progressive sans déclencher de tempêtes.

Règle opérationnelle : la swap utilisée sans E/S de swap peut être acceptable. La swap utilisée avec un fort swap-in/swap-out est là où les performances meurent.

La croissance de la swap n’est pas automatiquement un bug

Linux va déplacer opportunément des pages anonymes froides vers la swap pour laisser plus de RAM au cache de pages et aux métadonnées du système de fichiers. Sur un poste de travail,
cela peut être bénéfique. Sur un hyperviseur, ça dépend. Vos pages « froides » peuvent appartenir à des processus qemu qui en auront soudainement besoin. C’est là que vous voyez
une VM se figer pendant une seconde et que les utilisateurs inventent de nouveaux adjectifs.

Une distinction clé :

• Occupation de la swap : combien de swap est utilisée maintenant.
• Activité de la swap : combien de données passent par la swap par seconde.

L’occupation de la swap peut augmenter et rester élevée pendant des mois si le noyau a swapé des pages réellement froides et n’a jamais eu besoin de les récupérer. Ce n’est pas une alarme.
L’activité de swap pendant les heures de travail est une alarme. Une alarme calme, mais quand même.

Blague #1 : La swap, c’est comme un garde-meuble. Vous pouvez y laisser des choses pendant des années, mais le moment où vous en avez besoin en pleine réunion, vous regretterez tout.

Faits intéressants et contexte historique

1. Linux exposait autrefois la « free memory » en gros titre, et pendant des années les gens ont paniqué et tuné leurs systèmes ; les recommandations modernes insistent sur « available ».
2. Swappiness n’est pas « agressivité de swap » de façon simple ; elle influence l’équilibre de reclaim entre pages anonymes et cache de fichiers, et le comportement évolue selon l’époque du noyau.
3. L’OOM killer n’est pas un bug ; c’est Linux qui choisit « un processus doit mourir pour que le système vive », ce qui est souvent correct sur un hôte mais douloureux en virtualisation.
4. ZFS ARC est conçu pour consommer de la RAM car le cache est performant ; sans cap, il peut évincer les invités sur un hyperviseur.
5. Pressure Stall Information (PSI) est arrivé pour quantifier le « temps passé bloqué » sous pression — enfin transformer « ça paraît lent » en signal mesurable.
6. Les cgroups mémoire ont changé la donne en permettant le comptage mémoire par VM/conteneur et des comportements de reclaim par groupe — parfois améliorant l’isolation, parfois ajoutant des surprises.
7. KSM (Kernel Samepage Merging) a été important pour la densité de virtualisation, mais il échange CPU contre RAM et peut interagir avec le reclaim de façon inattendue.
8. Transparent Huge Pages ont été introduits pour les performances, mais en virtualisation ils peuvent accroître les pics de latence lors de la compaction et du reclaim.
9. Les heuristiques et valeurs par défaut de swappiness ont évolué parce que les SSD ont rendu le swap moins catastrophique que sur disques rotatifs — pourtant les E/S aléatoires de swap punissent toujours les charges sensibles à la latence.

Comment Linux décide de reclaimer la mémoire (et pourquoi Proxmox complique les choses)

Proxmox est « juste Debian », mais en production ce n’est jamais « juste ». Vous exécutez des processus qemu-kvm (gros consommateurs de mémoire anonyme), peut-être des conteneurs LXC,
et peut-être ZFS, un système de fichiers hautes performances qui adore utiliser beaucoup de RAM. Ensuite vous ajoutez le ballooning, qui est essentiellement un mensonge négocié :
« oui invité, vous avez toujours 16 Gio », pendant que l’hôte demande discrètement à les récupérer.

Trois catégories importent : anonymes, cache de fichiers et reclaimabilité

Quand la RAM se resserre, le noyau récupère la mémoire principalement en :

• Vidant le cache de fichiers (facile et rapide si le cache est jetable).
• Écrivant les pages dirty sur disque (peut être lent ; dépend du stockage).
• Swapant la mémoire anonyme (pages de processus non-backed par un fichier).

La virtualisation transforme la RAM invitée en pages anonymes de l’hôte. Cela signifie que le plus gros consommateur de RAM de l’hyperviseur est précisément le type de mémoire que Linux est prêt
à swapper s’il pense pouvoir garder le système réactif. Et vous voyez comment cela finit.

La pression mémoire n’est pas « peu de free »

Linux utilise volontiers la RAM pour le cache ; ce n’est pas du gaspillage. La métrique que vous voulez est MemAvailable (depuis /proc/meminfo) et, mieux,
les signaux PSI qui montrent si des tâches se retrouvent bloquées en attendant le reclaim.

ZFS complique le reclaim

ZFS ARC est techniquement reclaimable, mais ce n’est pas le « page cache » de la même manière qu’ext4. L’ARC entre en compétition avec les invités pour la mémoire. Si l’ARC croît sans limite,
l’hôte peut commencer à swapper des pages invitées tout en conservant beaucoup de cache ZFS. C’est un compromis que vous voulez rarement sur un hyperviseur : la latence des E/S de swap est pire qu’un ARC plus petit.

Le ballooning peut créer un « faux espace libre »

Le ballooning est acceptable quand il est utilisé intentionnellement (pour l’élasticité, pas pour le déni). Mais si vous sur-allouez et comptez sur le ballooning comme filet de sécurité,
vous pouvez pousser les invités dans leur propre reclaim pendant que l’hôte récupère aussi. Deux couches de reclaim. Deux fois plus de plaisir. Moitié stabilité.

Citation (idée paraphrasée) : « L’espoir n’est pas une stratégie » — couramment attribué aux responsables opérations ; prenez-le comme principe, pas comme citation.

Causes fréquentes de « la swap ne cesse de croître » sur Proxmox

1) Sur-engagement réel : vous avez alloué plus de mémoire que vous possédez

C’est le classique. Vous additionnez la « mémoire assignée » des VM et ça dépasse largement la RAM physique, puis vous êtes surpris que l’hôte utilise la swap.
L’hôte n’a pas tort. Votre feuille de calcul oui.

2) ZFS ARC grignote l’espace des invités

Sur une machine de stockage dédiée, laisser ARC utiliser la majeure partie de la mémoire est excellent. Sur un hyperviseur, l’ARC a besoin de limites. Sinon l’ARC devient « ce locataire »
qui prend tout l’espace de la cuisine et se vexe quand on lui demande de partager.

3) Swappiness et tuning du reclaim inadéquats pour un hyperviseur

Les valeurs par défaut sont raisonnables pour Linux général. Les hyperviseurs ne sont pas généraux. La mauvaise combinaison peut conduire à swap précoce des pages qemu alors que vider le cache aurait été moins coûteux.

4) Fragmentation mémoire / problèmes de compaction (THP et hugepages)

Si l’hôte a du mal à allouer de la mémoire contiguë, la compaction et le reclaim deviennent bruyants. Cela peut ressembler à « la swap ne cesse de croître », mais la cause racine est la latence et le temps CPU passé dans les chemins de reclaim.

5) Quelque chose fuit, mais pas là où vous pensez

Parfois c’est une fuite réelle : un agent de monitoring, un processus de sauvegarde, ou un conteneur qui part en vrille. Mais le plus souvent c’est une croissance régulière causée par du cache
(ZFS ARC, slab caches) qui ressemble à une fuite dans le mauvais tableau de bord.

6) Stockage lent rend la swap « collante »

Si votre périphérique de swap est lent ou saturé, les pages swapées ne reviennent pas rapidement. Le noyau peut les laisser swapées plus longtemps, faisant monter et rester élevée l’utilisation de la swap. Pas parce que le noyau adore la swap — parce que vos disques vous en veulent.

Blague #2 : Le noyau ne « swap pas au hasard ». Il swap avec la sérénité calme de quelqu’un qui sait que vous n’avez pas planifié la capacité et aimerait que vous appreniez.

Tâches pratiques : commandes, sorties, décisions

Ci‑dessous des tâches prêtes pour le terrain. Chacune contient : une commande, ce que signifie la sortie, et la décision à prendre. Exécutez-les d’abord sur l’hôte Proxmox.
Ensuite, si nécessaire, à l’intérieur d’un invité défaillant.

Task 1: Confirm swap occupancy and swap devices

cr0x@server:~$ swapon --show --bytes
NAME       TYPE SIZE        USED       PRIO
/dev/sda3  part 17179869184 4294967296  -2

Signification : Vous avez une partition de swap de 16 GiB et 4 GiB sont actuellement utilisées.
Décision : Si USED est élevé, ne paniquez pas tout de suite — vérifiez l’activité ensuite. Si la swap est sur un disque lent partagé avec le stockage des VM, envisagez de la déplacer.

Task 2: Check swap activity (the real “is this hurting?” metric)

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
 1  0 4194304 812344  53212 921344   0    0    12    30  400  700  3  2 94  1  0
 2  0 4194304 790112  53044 910020   0    0     0    64  420  760  4  3 92  1  0
 3  1 4194304 120312  52880 302120   0  512   120  2000  800 1500 20 10 55 15  0
 2  2 4194816  90344  52000 280000 128 1024   300  5000 1200 2000 25 12 40 23  0
 1  1 4198912  81200  51000 270000 256 2048   500  8000 1500 2500 22 15 35 28  0

Signification : si/so sont les KB/s de swap-in/swap-out. Dans les derniers échantillons ils sont non nuls et en hausse : swap actif.
Décision : Le swapping actif signifie impact de performance. Passez au diagnostic de pression ; planifiez de réduire la pression mémoire ou de modifier le comportement de reclaim.

Task 3: Check MemAvailable and swap totals

cr0x@server:~$ grep -E 'MemTotal|MemFree|MemAvailable|SwapTotal|SwapFree' /proc/meminfo
MemTotal:       263989996 kB
MemFree:         1123400 kB
MemAvailable:   34122388 kB
SwapTotal:      16777212 kB
SwapFree:       12582912 kB

Signification : MemFree est faible (normal), MemAvailable est ~32 GiB (bon espace).
Décision : Si MemAvailable est sain mais l’activité de swap est élevée, suspectez des pathologies de reclaim, un comportement de pression ARC/ZFS, ou des limites par cgroup.

Task 4: Read PSI memory pressure (are tasks stalling?)

cr0x@server:~$ cat /proc/pressure/memory
some avg10=0.15 avg60=0.20 avg300=0.35 total=18203456
full avg10=0.02 avg60=0.04 avg300=0.05 total=3401120

Signification : « some » est le temps où au moins une tâche était bloquée sur la mémoire ; « full » est le temps où toutes les tâches exécutables étaient bloquées.
Un « full » non trivial indique des blocages visibles par l’utilisateur.
Décision : Si PSI full est élevé pendant les fenêtres d’incident, considérez cela comme une vraie pression mémoire. Cessez de débattre « mais la RAM libre » et corrigez la capacité/le tuning.

Task 5: Identify if kswapd is burning CPU (reclaim is working overtime)

cr0x@server:~$ top -b -n 1 | head -n 20
top - 10:01:22 up 41 days,  3:12,  1 user,  load average: 6.20, 5.90, 5.10
Tasks: 412 total,   2 running, 410 sleeping,   0 stopped,   0 zombie
%Cpu(s): 22.1 us,  9.3 sy,  0.0 ni, 55.0 id, 13.2 wa,  0.0 hi,  0.4 si,  0.0 st
MiB Mem : 257802.0 total,   1140.2 free, 210000.4 used,  46661.4 buff/cache
MiB Swap:  16384.0 total,   8192.0 free,   8192.0 used.  43000.0 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
  158 root      20   0       0      0      0 R  48.0   0.0  120:11.2 kswapd0
 2210 root      20   0  9820.0m  12.2g  210.0m S  30.0   4.8  300:10.9 qemu-system-x86
  901 root      20   0  2120.0m  10.0g   50.0m S   8.0   4.0   90:22.2 pvestatd

Signification : kswapd0 à ~48% CPU indique un reclaim background intense.
Décision : Vous n’êtes pas seulement en train « d’utiliser la swap », vous payez en CPU et en latence pour cela. Investiguer ARC, le sur-engagement, et les tunables de reclaim.

Task 6: See what’s actually in RAM (anon vs file vs slab)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           252Gi       205Gi       1.1Gi       2.0Gi        45Gi        42Gi
Swap:           16Gi       8.0Gi       8.0Gi

Signification : Un fort used est normal ; concentrez-vous sur « available ». Ici available est 42 GiB, ce qui suggère que vous n’êtes pas coincé — sauf si ZFS/VMs ont besoin d’un burst.
Décision : Si available est bas (<~5–10% de la RAM) et que l’activité de swap est élevée, réduisez la charge ou augmentez la mémoire. Si available est élevé, concentrez-vous sur pourquoi la swap n’est pas récupérée (souvent « elle n’en a pas besoin »).

Task 7: Identify top swap consumers (per-process)

cr0x@server:~$ for pid in $(ls /proc | grep -E '^[0-9]+$'); do awk '/^VmSwap:/ {print $2 " " pid}' pid=$pid /proc/$pid/status 2>/dev/null; done | sort -nr | head
1048576 2210
524288  4120
262144  1987
131072  901
65536   3301

Signification : Le PID 2210 (probablement un processus qemu) a ~1 Gio swapé.
Décision : Si qemu swap fortement, traitez-le comme un problème côté hôte (sur-engagement/ARC/tuning). Si un démon aléatoire swap, corrigez/limitez ce processus.

Task 8: Map qemu PID to VMID (Proxmox-specific)

cr0x@server:~$ ps -p 2210 -o pid,cmd --no-headers
2210 /usr/bin/kvm -id 104 -name vm104 -m 16384 -smp 8 -drive file=/dev/zvol/rpool/vm-104-disk-0,if=virtio,cache=none

Signification : Ce processus swapé est le VMID 104 avec 16 GiB assignés.
Décision : Vérifiez la configuration mémoire de la VM (ballooning, min/max) et le sur-engagement de l’hôte. Si c’est une VM critique, priorisez la stabilisation du reclaim de l’hôte.

Task 9: Check Proxmox memory allocation vs physical (sanity, not perfection)

cr0x@server:~$ qm list
 VMID NAME         STATUS     MEM(MB)    BOOTDISK(GB) PID
 101  app01        running    32768             64.00 2101
 104  db01         running    16384            200.00 2210
 105  cache01      running    32768             32.00 2302
 110  winbuild     running    24576            120.00 2410

Signification : La mémoire assignée s’additionne vite ; le ballooning peut la masquer, mais la physique ne ment pas.
Décision : Si vous êtes proche ou au-delà de la RAM de l’hôte, arrêtez. Réduisez les allocations, appliquez des limites, ou ajoutez des nœuds/de la RAM. « Mais les invités n’utilisent pas » est le début des incidents.

Task 10: Check ballooning settings for a VM

cr0x@server:~$ qm config 104 | grep -E 'memory|balloon'
balloon: 4096
memory: 16384

Signification : La VM a 16 GiB max, target balloon 4 GiB (reclaim très agressif).
Décision : Si la cible balloon est bien en dessous du working set réel, vous forcez le reclaim invité puis le reclaim hôte. Envisagez d’augmenter le minimum ou de désactiver le ballooning pour les VM sensibles à la latence.

Task 11: If you use ZFS, check ARC size and ARC pressure

cr0x@server:~$ arcstat 1 1
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
10:03:41   220    12      5     3  1.3     9  3.7     0  0.0   96.0G  110.0G

Signification : La taille ARC est ~96 GiB, cap target c ~110 GiB. C’est beaucoup sur un hyperviseur, selon la RAM totale et les besoins des VM.
Décision : Si l’ARC est grand alors que les invités swapent, limitez l’ARC. La stabilité de l’hyperviseur prime sur des gains marginaux de cache lecture.

Task 12: Confirm ZFS ARC max (if set) and decide whether to cap it

cr0x@server:~$ grep -R "zfs_arc_max" /etc/modprobe.d /etc/sysctl.conf /etc/sysctl.d 2>/dev/null
/etc/modprobe.d/zfs.conf:options zfs zfs_arc_max=68719476736

Signification : ARC max est fixé à 64 GiB (en octets). Bien : au moins il est borné.
Décision : Si vous avez des reclaim fréquents et une activité de swap, baissez zfs_arc_max (avec prudence) pour laisser de la marge aux invités. Si vous êtes orienté stockage et peu de VM, gardez-le plus haut.

Task 13: Check kernel swappiness and dirty writeback behavior

cr0x@server:~$ sysctl vm.swappiness vm.dirty_ratio vm.dirty_background_ratio
vm.swappiness = 60
vm.dirty_ratio = 20
vm.dirty_background_ratio = 10

Signification : Swappiness 60 est assez par défaut. Les ratios dirty définissent quand le noyau commence à forcer les écritures.
Décision : Sur les hyperviseurs, une position courante est de réduire swappiness (ex. 1–10) pour décourager le swap de la mémoire qemu, sauf si vous savez tirer profit de la swap. Ajustez les dirty ratios si vous voyez des stalls de writeback.

Task 14: Inspect major page faults (a sign of swap-ins and cache misses)

cr0x@server:~$ pidstat -r -p 2210 1 3
Linux 6.2.16 (server)  12/26/2025  _x86_64_ (32 CPU)

10:05:12 AM   PID  minflt/s  majflt/s     VSZ     RSS   %MEM  Command
10:05:13 AM  2210   1200.00    45.00 10055680 12582912   4.8  qemu-system-x86
10:05:14 AM  2210   1100.00    60.00 10055680 12583104   4.8  qemu-system-x86
10:05:15 AM  2210   1300.00    55.00 10055680 12583360   4.8  qemu-system-x86

Signification : Les major faults (majflt/s) impliquent souvent des I/O disque (y compris des swap-ins). Ces chiffres sont assez élevés pour s’en préoccuper.
Décision : De forts major faults pour qemu sous charge corrèlent avec du swap ou une forte pression mémoire. Réduisez la pression ou améliorez le périphérique de swap et le comportement de reclaim.

Task 15: Check THP status (can contribute to reclaim/compaction pain)

cr0x@server:~$ cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

Signification : THP est réglé sur always. Cela peut aller, mais sur certaines charges de virtualisation cela augmente les pics de latence.
Décision : Si vous voyez des stalls de compaction/reclaim, essayez madvise au lieu de always et mesurez. Ne faites pas de cargo-cult : testez sur un nœud d’abord.

Task 16: Find out if swap is on slow or contended storage

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,ROTA,MOUNTPOINTS
NAME   TYPE   SIZE ROTA MOUNTPOINTS
sda    disk   1.8T    1
├─sda1 part   512M    1 /boot/efi
├─sda2 part     1G    1 /boot
└─sda3 part    16G    1 [SWAP]
└─sda4 part   1.8T    1
nvme0n1 disk  1.9T    0
└─nvme0n1p1 part 1.9T    0 /

Signification : La swap est sur un disque rotatif (ROTA=1) tandis que l’OS est sur NVMe. C’est un signal de performance.
Décision : Déplacez la swap vers un stockage plus rapide (NVMe) ou utilisez zram pour absorber les pics. Une swap rotative sur un hyperviseur chargé est une fabrique de latence.

Task 17: Check whether you’re hitting memory cgroup limits (containers especially)

cr0x@server:~$ systemd-cgtop -m -n 1
Control Group                           Memory Current  Memory Peak  Memory Swap  IO Read  IO Write
/                                         210.0G        211.2G        8.0G        2.1M     30.4M
/system.slice/pve-container@112.service      3.2G          3.4G        1.5G          0B       12K
/system.slice/pve-container@113.service      7.8G          8.0G        2.0G          0B       18K

Signification : Les conteneurs peuvent aussi utiliser la swap ; « memory.swap » montre la consommation de swap par cgroup.
Décision : Si un conteneur est le gros consommateur de swap, corrigez sa limite ou sa charge. Les réglages hôtes ne feront pas bien se comporter un conteneur mal dimensionné.

Task 18: Drain swap safely (when you’ve fixed the cause)

cr0x@server:~$ sudo sysctl -w vm.swappiness=1
vm.swappiness = 1
cr0x@server:~$ sudo swapoff -a && sudo swapon -a
cr0x@server:~$ swapon --show
NAME      TYPE SIZE  USED PRIO
/dev/sda3 part  16G    0B   -2

Signification : La swap a été vidée et réactivée.
Décision : Ne faites cela que lorsque MemAvailable est confortablement élevé et que l’activité de swap est faible. Sinon, swapoff peut déclencher une tempête mémoire et un OOM.

Trois mini-récits d’entreprise issus des mines de swap

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une PME SaaS exploitait un cluster Proxmox hébergeant des services internes « divers » : runners CI, une pile métrique, quelques bases de données sans propriétaire,
et une VM Windows qui existait parce que quelqu’un avait eu besoin de Visio une fois. Les hôtes avaient beaucoup de RAM sur le papier. La swap montait quand même, lentement, comme une mauvaise humeur.

L’hypothèse erronée était simple : « Si free montre des dizaines de gigaoctets disponibles, le système ne peut pas être sous pression mémoire. » Ils ont regardé
MemAvailable et déclaré victoire. Pendant ce temps, les utilisateurs se plaignaient de courtes pauses — 30 secondes de rien — puis tout « reprenait ».

La clé était PSI. Pendant les pauses, la métrique memory PSI « full » grimpait. kswapd prenait un cœur CPU pendant de longues périodes. Les E/S de swap étaient mesurables, pas énormes, mais constantes.
Ce n’était pas un manque de mémoire en moyenne ; c’était un manque de mémoire au moment où on en avait besoin, et le reclaim ne suivait pas.

Cause racine : quelques VM avaient des targets balloon réglées très bas par rapport à leurs working sets réels. L’hôte récupérait agressivement des invités, les invités paginaient,
puis l’hôte paginait aussi. Deux couches de paging ont créé des pics de latence. La correction a été ennuyeuse : désactiver le ballooning pour les VM sensibles à la latence, définir des minimums réalistes
pour les autres, et cesser de prétendre que l’overcommit est « gratuit ».

La swap « a continué de croître » après la correction, mais l’activité de swap est devenue quasi nulle. C’est ça l’important. Ils ont arrêté de redémarrer les hôtes comme rituel de bien-être.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation a décidé d’« optimiser les E/S » en déplaçant la swap sur un zvol ZFS du même pool que les disques VM, parce que c’était pratique et que les snapshots étaient cool.
Ça fonctionnait en labo. Tout fonctionne en labo. Le labo est l’endroit où la physique fait la sieste.

En production, lors d’un événement de pression mémoire léger (une VM DB lançant une reconstruction d’index ponctuelle), l’activité de swap a augmenté. ZFS a commencé à travailler plus.
L’ARC a grandi parce que la charge était orientée lecture. Le pool est devenu occupé. Les E/S de swap ont concurrencé les E/S disques des VM. La latence a grimpé. Les invités ont ralenti.

L’équipe a répondu en augmentant la taille de la swap. Cela a réduit les OOM mais augmenté le temps passé dans la misère. Ils ont transformé « échouer vite » en « échouer lentement pendant que tout le monde regarde les tableaux de bord ».

La correction : déplacer la swap hors du pool ZFS et sur un stockage local rapide dédié (ou zram pour les pics). Limiter l’ARC. Éloigner les E/S de swap de la file d’attente sur laquelle dépendent vos VM. Parfois, la bonne optimisation est de séparer les responsabilités, pas de gratter des microsecondes.

La leçon retenue : « Les architectures pratiques sont le punching-ball préféré de la production. »

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

Une entreprise liée à la finance avait un cluster Proxmox qui ne faisait jamais la une. Pas parce qu’il était magique — parce qu’il était exploité avec la discipline qui paraît peu impressionnante jusqu’à ce qu’elle manque.

Ils gardaient un simple rapport hebdomadaire : tendances MemAvailable par nœud, moyennes PSI, taux d’E/S de swap, et principaux consommateurs de swap. Pas des métriques de vanité ; celles
que l’on utilise pour détecter des changements lents. Ils appliquaient aussi une politique : les allocations mémoire VM ne pouvaient pas dépasser un seuil de marge défini sans justification par ticket.

Une semaine, PSI « some » a dérivé à la hausse sur deux nœuds. L’E/S de swap restait faible, mais le CPU de kswapd a augmenté. Rien n’était cassé encore. C’est le meilleur moment pour agir.
Ils ont trouvé une nouvelle VM d’ingestion de logs avec une limite mémoire trop haute et un ballooning trop bas, provoquant une pression de reclaim hôte lors des pics d’ingestion.

Ils ont ajusté la mémoire de la VM, défini un minimum balloon raisonnable, et resserré légèrement zfs_arc_max. Les nœuds n’ont jamais atteint le précipice. Pas d’incident. Pas de drame nocturne « pourquoi l’hyperviseur swap ».
Le graphique ennuyeux a sauvé la mise parce qu’il rendait visible le « presque cassé ».

Si vous voulez de la fiabilité, vous n’avez pas besoin d’héroïsme. Vous avez besoin de signaux précoces et de permission pour agir sur eux.

Erreurs courantes : symptôme → cause racine → correctif

1) Symptom: swap used is high, but performance is fine

Cause racine : Des pages froides ont été swapées et n’ont jamais été rappelées. L’activité de swap est quasi nulle.

Correctif : Ne rien faire. Surveillez PSI et les E/S de swap. Ne lancez pas « swapoff -a » juste pour vous sentir propre.

2) Symptom: swap used grows daily, kswapd high CPU, short VM freezes

Cause racine : Pression mémoire soutenue ou boucle de reclaim ; souvent sur-engagement de VM plus ARC ZFS ou ballooning.

Correctif : Réduire les allocations ou déplacer des VM ; limiter ARC ; baisser swappiness ; désactiver ou contraindre le ballooning ; vérifier que PSI baisse.

3) Symptom: host has plenty of MemAvailable but swap I/O is high

Cause racine : Déséquilibre de reclaim ou pression mémoire par cgroup (conteneurs/config VM), ou stalls THP/compaction créant des schémas de pression.

Correctif : Inspecter PSI et l’usage par cgroup ; tuner swappiness ; envisager THP=madvice ; garantir une swap rapide.

4) Symptom: after adding swap, system stops OOMing but becomes sluggish

Cause racine : Vous avez converti une défaillance nette en thrashing. La swap masque les problèmes de capacité.

Correctif : Redimensionner les engagements RAM ; garder la swap modérée ; utiliser la swap pour la sécurité, pas pour l’état normal.

5) Symptom: swapping spikes during backups/scrubs

Cause racine : Les I/O intensives provoquent des stalls de writeback et des retards de reclaim ; les scrubs ZFS peuvent modifier le comportement du cache et la pression.

Correctif : Planifier les I/O lourdes ; limiter ARC ; tuner les dirty ratios si writeback stalle ; assurer que la swap n’est pas sur le même périphérique occupé.

6) Symptom: one VM is “fine” but everything else is slow

Cause racine : Une VM ou un conteneur force l’hôte en reclaim (hog mémoire), souvent dû à une mauvaise taille ou une charge incontrôlée.

Correctif : Identifier les principaux consommateurs de swap ; limiter l’offenseur ; définir une mémoire VM réaliste ; isoler les charges bruyantes sur des nœuds dédiés.

7) Symptom: swap keeps growing after migration changes

Cause racine : Changements de localité mémoire, ARC qui se réchauffe différemment, ou comportement modifié de KSM/THP. Aussi : des pages swapées persistent et ne reviennent pas automatiquement.

Correctif : Re-mesurer l’activité de swap et PSI. Si c’est calme, acceptez. Sinon, tunez puis, éventuellement, drainer la swap pendant une fenêtre de maintenance.

Listes de contrôle / plan étape par étape

Step-by-step: stabilize a Proxmox host that’s swapping under load

1. Mesurez l’activité, pas les impressions.
   Utilisez vmstat 1, PSI, et pidstat pour confirmer le swapping actif et les stalls.
2. Trouvez la source de pression.
   Identifiez les principaux consommateurs de swap ; mappez les PIDs qemu aux VMID ; vérifiez les cgroups conteneurs.
3. Vérifiez les engagements.
   Comparez la RAM physique au total assigné. Si vous êtes sur-engagé sans plan, c’est le plan qui échoue.
4. Corrigez la politique de ballooning.
   Pour les VM sensibles à la latence : désactivez le ballooning ou définissez un minimum réaliste. Pour les autres : gardez un ballooning conservateur.
5. Limitez ZFS ARC si vous utilisez ZFS.
   Décidez d’un budget : laissez de la marge pour l’hôte + les pics VM. Appliquez et surveillez.
6. Rendez la swap rapide ou réduisez-la.
   Placez la swap sur NVMe si nécessaire ; évitez de la mettre sur le même pool contendu que les disques VM.
7. Tunez légèrement le reclaim, puis re-mesurez.
   Ajustez swappiness (courant : 1–10 pour hyperviseurs), pensez THP=madvice, et surveillez PSI et les E/S de swap.
8. Ce n’est qu’ensuite que vous drainer la swap (optionnel).
   Utilisez swapoff/swapon pendant une fenêtre de faible charge si l’occupation de la swap vous dérange ou si vous avez besoin d’un état propre.
9. Mettez en place des garde-fous.
   Alertes sur PSI full, taux d’E/S de swap, et CPU de kswapd. Un tableau de bord n’est utile que s’il change le comportement.

Checklist: what “good” looks like on a stable Proxmox node

• MemAvailable reste au‑dessus d’un plancher confortable sous la charge de pointe normale (définissez-le ; ne devinez pas).
• PSI memory « full » est proche de zéro la plupart du temps ; « some » est faible et stable.
• L’E/S de swap est proche de zéro en steady-state ; la swap utilisée peut être non nulle et c’est acceptable.
• kswapd n’est pas un des plus gros consommateurs CPU.
• ZFS ARC est limité (si ZFS) et n’affame pas les invités.
• Le ballooning est délibéré, pas laissé par défaut dans le chaos.

Checklist: when to add RAM vs when to tune

• Ajouter de la RAM quand PSI montre des stalls soutenus et que vous ne pouvez pas réduire les engagements sans impact métier.
• Tuner quand l’activité de swap est élevée mais qu’il y a de la marge, ou quand un choix de configuration (ARC/ballooning/emplacement swap) est manifestement mauvais.
• Ré-architecturer quand votre objectif de densité nécessite un overcommit permanent et que vous n’avez pas de prévisibilité des charges. C’est une décision stratégique, pas un sysctl.

FAQ

1) Pourquoi l’utilisation de la swap continue-t-elle d’augmenter alors que la RAM « semble correcte » ?

Parce que l’utilisation de la swap est collante. Linux peut swapper des pages froides et ne jamais se donner la peine de les ramener si ce n’est pas nécessaire. Si l’E/S de swap est faible et PSI calme,
ce n’est pas forcément un problème.

2) Dois-je mettre vm.swappiness=1 sur Proxmox ?

Souvent oui pour les hyperviseurs, car swapper la mémoire qemu nuit à la latence. Mais ne le traitez pas comme un numéro magique. Mesurez l’E/S de swap et PSI avant et après.
Si vous exécutez des charges lourdes basées sur le cache fichier ou ZFS, vous devez toujours gérer ARC et les engagements.

3) Est-il sûr de fonctionner sans swap ?

C’est « sûr » dans le sens où vous atteindrez l’OOM plus tôt et plus brutalement. Certains environnements préfèrent cela plutôt que le thrashing. La plupart des hyperviseurs de production gardent un peu de swap
comme tampon d’urgence, mais s’appuient sur la planification de capacité pour que la swap ne soit pas utilisée en charge normale.

4) Ma swap est utilisée mais swap-in/out est zéro. Dois-je la vider ?

Pas d’urgence. Vider la swap force ces pages en RAM, ce qui peut provoquer une pression transitoire. Si vous voulez un état propre, videz-la pendant une fenêtre de maintenance avec suffisamment de MemAvailable.

5) Est-ce que ZFS ARC « cause » le swapping ?

L’ARC ne force pas directement le swap, mais il concurrence la RAM. Si vous laissez l’ARC grandir sur un hyperviseur, le noyau peut reclaimer des pages anonymes (vos VM) pendant que l’ARC reste gros.
Limiter l’ARC est une mesure courante pour stabiliser Proxmox+ZFS.

6) La swap doit-elle vivre sur un zvol ZFS ?

Vous pouvez, mais généralement vous ne devriez pas sur un hyperviseur occupé. Les E/S de swap concourent avec les E/S disques des VM et peuvent amplifier la latence. Privilégiez un stockage local rapide
dédié ou zram pour absorber les pics, selon vos contraintes.

7) Le ballooning est-il bon ou mauvais ?

C’est un outil. Il est bon quand vous l’utilisez pour récupérer vraiment de la mémoire inutilisée des invités et que vous définissez des minimums réalistes. Il est mauvais quand vous l’utilisez comme béquille pour un overcommit
et que vous vous demandez ensuite pourquoi invités et hôtes paginent simultanément sous charge.

8) Comment savoir si le swapping nuit aux VM ?

Cherchez l’E/S de swap sur l’hôte (vmstat), des major faults élevés dans les processus qemu, PSI memory « full », CPU de kswapd, et des symptômes côté VM comme des pics de latence et du IO wait. L’utilisation de la swap seule ne suffit pas.

9) THP peut-il provoquer la croissance de la swap ?

THP concerne davantage le coût de compaction et de reclaim que l’occupation de la swap directement. Mais si THP « always » entraîne fréquemment des stalls de compaction et du churn de reclaim,
vous pouvez observer plus de swapping et de latence. Si vous en doutez, essayez THP=madvice et mesurez.

10) Quelle est la mesure de stabilisation la plus fiable ?

Cessez de mentir à la machine sur la mémoire. Gardez les engagements dans la réalité physique (avec marge), limitez ARC si vous utilisez ZFS, et rendez le ballooning conservateur.
Ensuite, ajustez swappiness et l’emplacement du swap comme raffinements.

Conclusion : prochaines étapes pour stabiliser réellement

« La swap ne cesse de croître » n’est effrayant que lorsqu’elle est couplée à de la pression et de l’activité. Votre travail est de séparer occupation et thrash,
puis d’enlever la raison pour laquelle l’hôte est forcé à faire des compromis laids.

Faites ceci ensuite :

1. Capturer un échantillon de 10 minutes pendant le pic : vmstat 1, PSI (/proc/pressure/memory), processus principaux, et major faults par qemu.
2. Mapper les consommateurs de swap aux VMID ; vérifier que ballooning et tailles mémoire ne sont pas fantaisistes.
3. Si vous utilisez ZFS : limitez l’ARC à un budget délibéré qui laisse de la marge aux VM.
4. Déplacez la swap sur un stockage rapide ou utilisez zram si vous avez besoin d’un tampon de pic ; évitez les pools contendus.
5. Réglez swappiness bas (et persistez-le) une fois que vous avez confirmé que cela améliore l’activité de swap et les stalls.
6. Uniquement après stabilité : éventuellement vider la swap pendant une fenêtre calme pour réinitialiser les baselines.

L’objectif n’est pas « zéro swap utilisée ». L’objectif est « pas de stalls mémoire, pas de thrash, et une latence prédictible ». L’ennui est une fonctionnalité.