Pièges du swapfile sur Debian 13 : le créer correctement (permissions, fstab, priorité)

Faits et contexte (pourquoi les swapfiles posent encore problème)

Les swapfiles ne sont pas nouveaux. Ce qui est nouveau, c’est le nombre de couches qui peuvent interférer : systèmes de fichiers copy-on-write, chiffrement, limites mémoire des cgroups, zram, et l’ordre des unités systemd. Un swapfile peut exister, être « activé », et pourtant être inutile (ou nuisible) s’il est lent, fragmenté, placé sur un mauvais système de fichiers, ou en concurrence avec un autre périphérique de swap ayant une priorité plus élevée.

8 faits courts et un peu d’histoire

1. Le swap est antérieur à Linux : les systèmes de type UNIX utilisent la pagination depuis les années 1970 ; Linux a hérité du concept et a beaucoup itéré sur le comportement de la VM depuis.
2. Les partitions de swap étaient la réponse par défaut parce qu’elles étaient prévisibles : blocs contigus, pas de surprises liées aux métadonnées du système de fichiers.
3. Les swapfiles étaient historiquement « de seconde zone » sur certains systèmes de fichiers parce que le mappage des blocs était plus difficile, la fragmentation comptait davantage, et les besoins d’hibernation étaient stricts.
4. Les noyaux modernes peuvent utiliser efficacement les swapfiles sur des systèmes de fichiers traditionnels (ext4/XFS) si le fichier est correctement alloué et non sparse — pourtant des gens créent encore des swapfiles sparse par accident.
5. Btrfs a rendu les swapfiles compliqués : copy-on-write et compression entrent en conflit avec les attentes du swap. Les noyaux modernes le supportent avec des contraintes (nocow, pas de compression, allocation correcte), mais il est encore facile de se tromper.
6. La priorité existe depuis longtemps : Linux peut répartir les E/S de swap entre des zones de priorité égale ; ce n’est pas juste « choisir un seul ». Des priorités mal réglées créent des comportements surprenants.
7. La swappiness n’est pas un « réglage de vitesse » ; c’est un réglage de politique. Beaucoup d’équipes l’utilisent à tort comme solution de performance, puis s’étonnent d’une aggravation de la latence sous pression.
8. L’hibernation est une autre affaire : elle exige que le chemin de resume trouve exactement la zone de swap contenant l’image ; les swapfiles peuvent fonctionner, mais seulement si la configuration de reprise correspond à la réalité.

Une citation à garder près du terminal :

« L’espoir n’est pas une stratégie. » — Gen. Gordon R. Sullivan

La configuration du swap est l’endroit parfait pour arrêter d’espérer.

À quoi ressemble une configuration “bonne” sur Debian 13

Une configuration correcte de swapfile sur Debian 13 présente ces propriétés :

• Le swapfile est non sparse (blocs réels alloués).
• Les permissions sont 0600, appartenant à root.
• Il réside sur un système de fichiers qui prend en charge les swapfiles de manière sûre pour votre cas d’usage (ext4 et XFS sont fiables ; Btrfs nécessite des précautions supplémentaires ; ZFS est une discussion à part).
• Il est activé au démarrage via /etc/fstab (ou une unité systemd), et vous pouvez le prouver avec swapon --show.
• La priorité est délibérée : vous savez quelle zone de swap doit être utilisée en premier, et pourquoi.
• Une supervision est en place : vous pouvez voir la pression mémoire, l’utilisation du swap, et les défauts majeurs de pages avant que les utilisateurs ne signalent des délais d’attente.

Deux vérités sur le swap que vous pouvez afficher :

• Le swap n’est pas un substitut à la planification de capacité. C’est un filet de sécurité, pas un matelas.
• Si vous comptez sur le swap pour la performance en régime permanent, vous construisez un générateur de latence.

Blague #1 : Le swap, c’est comme la caféine : utile en cas d’urgence, mais si c’est votre alimentation quotidienne, quelque chose en amont est cassé.

Pratique de diagnostic rapide

Quand un système Debian paraît lent et que vous suspectez le swap, vous voulez identifier le goulot d’étranglement en minutes, pas en heures. Voici l’ordre qui permet systématiquement d’atteindre la cause racine.

Première étape : confirmez que le swap existe et est actif

• Vérifiez les zones de swap activées et leurs priorités.
• Confirmez que le swapfile n’est pas silencieusement ignoré à cause des permissions ou des contraintes du système de fichiers.

Deuxième étape : confirmez que vous avez une pression mémoire (et pas seulement CPU ou I/O)

• Vérifiez MemAvailable, le taux swap in/out et les défauts majeurs.
• Cherchez des kills OOM : ce sont les symptômes les plus parlants d’un « swap absent ou inefficace ».

Troisième étape : déterminez si le swap aide ou nuit

• Si les E/S de swap sont élevées et que la latence disque augmente, vous êtes en situation de thrash.
• Si l’utilisation du swap est modérée et stable et que la machine reste réactive, le swap fait son travail.

Quatrième étape : isolez la charge responsable

• Identifiez les processus dont le RSS croit ou qui provoquent des défauts de pages.
• Vérifiez les limites des cgroups et les paramètres mémoire des conteneurs si applicable.

Cinquième étape : décidez de l’action

• À court terme : ajouter de la RAM, ajouter du swap, réduire la concurrence ou tuer les processus hors de contrôle.
• À moyen terme : corriger les fuites mémoire, dimensionner correctement, et assurer que la configuration du swap est saine.

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

Ci-dessous des tâches pratiques à exécuter sur Debian 13. Chaque tâche inclut : la commande, ce que signifie une sortie typique, et la décision à prendre. C’est la trousse « arrêtez de deviner ».

Task 1 — Voir si le swap est activé (et la priorité)

cr0x@server:~$ swapon --show --output=NAME,TYPE,SIZE,USED,PRIO
NAME      TYPE  SIZE  USED PRIO
/swapfile file   8G  256M   -2

Signification : Le swap est activé et utilisé (256M). La priorité est -2 ; les priorités négatives sont normales pour les swapfiles sauf si vous la spécifiez.

Décision : Si rien n’apparaît, vous n’avez pas de swap actif. Corrigez cela avant d’ajuster autre chose.

Task 2 — Vérifier que le noyau reconnaît le swap

cr0x@server:~$ cat /proc/swaps
Filename                                Type            Size            Used            Priority
/swapfile                               file            8388604         262144          -2

Signification : Le noyau voit le swapfile ; la taille et l’utilisé sont en KiB.

Décision : Si le swapfile est absent ici mais présent sur le disque, l’activation a échoué — vérifiez les permissions, fstab, et les contraintes du système de fichiers.

Task 3 — Vérifier rapidement la pression mémoire

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        27Gi       1.2Gi       412Mi       3.0Gi       2.8Gi
Swap:          8.0Gi       256Mi       7.8Gi

Signification : « available » est le meilleur indicateur rapide ; 2.8Gi available suggère une pression présente mais pas catastrophique. Le swap est peu utilisé.

Décision : Si « available » est minime et que l’utilisation du swap grimpe rapidement, vous êtes en route vers le thrash ou l’OOM.

Task 4 — Déterminer si le swapping est actif maintenant

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  0 262144 1248932 212344 2912456    0    0    12    45  241  512  9  3 87  1  0
 1  0 262144 1251120 212352 2911988    0    0     0    16  198  430  7  2 90  1  0
 3  1 270336  312144 212360 3014332  512 1024   800  1200  412  980 18  7 52 23  0
 2  1 285696  140512 212368 3040012  768 2048   900  1500  430 1100 20  8 41 31  0
 1  0 285696  210224 212376 3038008    0    0   110   220  260  600 11  4 83  2  0

Signification : Les colonnes si/so montrent le swap-in/out par seconde. Des pics (512/1024 etc.) indiquent un swapping actif.

Décision : Si si/so soutenus sont non nuls et que wa augmente, vous avez probablement à la fois une pression mémoire et une contention I/O. Identifiez la charge et envisagez d’ajouter de la RAM ou de réduire l’empreinte mémoire.

Task 5 — Vérifier les kills OOM (le reçu « vous n’aviez pas de plan »)

cr0x@server:~$ journalctl -k -g "Out of memory" -n 10 --no-pager
Dec 30 10:12:44 server kernel: Out of memory: Killed process 24891 (java) total-vm:14688208kB, anon-rss:12710492kB, file-rss:1420kB, shmem-rss:0kB, UID:1000 pgtables:27820kB oom_score_adj:0

Signification : Le noyau a tué un processus parce qu’il ne pouvait pas récupérer assez de mémoire rapidement.

Décision : Si un OOM survient et que le swap est absent ou minuscule, ajoutez du swap comme filet de sécurité — mais corrigez aussi la demande mémoire. Si le swap existe et qu’un OOM se produit quand même, il se peut que le swap soit inutilisable (problème de système de fichiers) ou que des limites memcg s’appliquent.

Task 6 — Confirmer les permissions du swapfile (sécurité et correction)

cr0x@server:~$ ls -lh /swapfile
-rw------- 1 root root 8.0G Dec 30 09:58 /swapfile

Signification : -rw------- correspond à 0600. C’est ce que vous voulez. Le swap peut contenir des données sensibles.

Décision : Si vous voyez 0644 ou autre chose que 0600, corrigez immédiatement et réactivez le swap si nécessaire.

Task 7 — Détecter un swapfile sparse (problèmes de performance et d’activation silencieux)

cr0x@server:~$ filefrag -v /swapfile | head
Filesystem type is: ef53
File size of /swapfile is 8589934592 (2097152 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..  65535:   532480..  598015:  65536:
   1:    65536.. 131071:   598016..  663551:  65536:
   2:   131072.. 196607:   663552..  729087:  65536:
 /swapfile: 3 extents found

Signification : Peu d’extents est bon : probablement suffisamment contigu. Un fichier sparse afficherait des trous, et certains outils avertiront à l’activation.

Décision : Si vous voyez beaucoup d’extents (des centaines/milliers) sur des disques rotatifs, attendez-vous à des E/S de swap douloureuses. Recréez le swapfile avec une méthode qui alloue de façon contiguë, et gardez-le sur un stockage rapide.

Task 8 — Confirmer le type de système de fichiers sous le swapfile

cr0x@server:~$ findmnt -no FSTYPE,TARGET /swapfile
ext4 /

Signification : Le swapfile est sur ext4 : généralement sûr et simple.

Décision : Si c’est sur btrfs ou zfs, lisez la section des pièges du système de fichiers avant de déclarer victoire.

Task 9 — Vérifier que l’entrée fstab est utilisée (et non ignorée)

cr0x@server:~$ grep -nE 'swap|swapfile' /etc/fstab
12:/swapfile none swap sw,pri=10 0 0

Signification : Vous avez une entrée explicite de swapfile avec priorité 10.

Décision : S’il n’y a pas de ligne de swap, vous dépendez d’un swapon manuel ou d’un outil de distribution. Pour des serveurs, rendez le comportement au démarrage déterministe via fstab ou systemd.

Task 10 — Tester l’activation maintenant (attraper les erreurs immédiatement)

cr0x@server:~$ sudo swapoff /swapfile
cr0x@server:~$ sudo swapon /swapfile
cr0x@server:~$ swapon --show
NAME      TYPE  SIZE USED PRIO
/swapfile file   8G   0B   10

Signification : La réactivation a réussi et la priorité a été appliquée.

Décision : Si swapon renvoie une erreur (permissions, trous, non supporté), corrigez le problème sous-jacent plutôt que de forcer.

Task 11 — Mesurer les symptômes de latence I/O du périphérique de swap

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

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          14.21    0.00    5.10   18.33    0.00   62.36

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
nvme0n1          8.00    512.0     0.00   0.00   0.45    64.0     65.00   8192.0     0.00   0.00   4.80   126.0   0.32  12.00

Signification : Un iowait élevé accompagné de forts débits d’écriture peut être du swap-out. Sur NVMe, quelques ms peuvent être acceptables ; sur HDD, c’est là que les systèmes meurent lentement.

Décision : Si %iowait et l’await grimpent pendant la pression mémoire, le swap contribue au problème ; déplacez le swap sur un stockage plus rapide ou réduisez le swapping.

Task 12 — Inspecter la swappiness et décider si la toucher

cr0x@server:~$ sysctl vm.swappiness
vm.swappiness = 60

Signification : Comportement plutôt par défaut : le noyau swapera sous pression mémoire avec une politique équilibrée.

Décision : Ne pratiquez pas le cargo-cult vm.swappiness=1. Ajustez uniquement avec un objectif clair : par exemple, charges sensibles à la latence qui doivent éviter le swap, ou systèmes contraints en mémoire où vous préférez récupérer le cache plus tôt.

Task 13 — Confirmer si zram est présent (et en concurrence)

cr0x@server:~$ swapon --show --output=NAME,TYPE,SIZE,USED,PRIO
/dev/zram0 partition  2G  0B   100
/swapfile  file       8G  0B    10

Signification : zram a une priorité beaucoup plus élevée, il sera donc utilisé en premier.

Décision : C’est généralement bien (swap compressé en RAM est rapide), mais vous devez savoir qu’il existe sinon vous interpréterez mal les résultats de performance. Si zram est trop petit, vous pouvez quand même atteindre le swap disque sous forte pression.

Task 14 — Si vous tenez à l’hibernation : localiser l’offset du swap (swapfile uniquement)

cr0x@server:~$ sudo filefrag -v /swapfile | awk '/^ *0:/{print $4}' | tr -d '.'
532480

Signification : C’est l’offset physique du premier extent (unités de blocs du système de fichiers), utilisé par certaines configurations d’hibernation pour calculer resume_offset.

Décision : Si vous hibernez, vous avez besoin d’un mappage de swapfile stable et d’une configuration de reprise correcte. Si vous n’hibernez pas, n’adaptez pas excessivement votre système à un cas d’usage que vous n’avez pas.

Créer un swapfile correctement et sans fantaisie

Il y a deux approches générales : allouer des blocs avec fallocate, ou écrire des zéros avec dd. Sur ext4/XFS modernes, fallocate est généralement rapide et correct. Sur certains systèmes de fichiers ou configurations, fallocate peut créer des extents indésirables, ou échouer complètement. L’idée n’est pas idéologique ; c’est un comportement prévisible.

Recommandé : swapfile ext4/XFS avec fallocate

C’est la voie propre pour la plupart des serveurs Debian 13 sur ext4/XFS.

cr0x@server:~$ sudo swapoff -a
cr0x@server:~$ sudo rm -f /swapfile
cr0x@server:~$ sudo fallocate -l 8G /swapfile
cr0x@server:~$ sudo chmod 600 /swapfile
cr0x@server:~$ sudo mkswap /swapfile
Setting up swapspace version 1, size = 8 GiB (8589930496 bytes)
no label, UUID=8b0a9a2e-35e6-4f1a-bf94-7a843e62c2e6
cr0x@server:~$ sudo swapon /swapfile
cr0x@server:~$ swapon --show
NAME      TYPE  SIZE USED PRIO
/swapfile file   8G   0B   -2

Pourquoi ces étapes, dans cet ordre :

• swapoff -a assure que vous ne modifiez pas une zone de swap active (oui, des gens le font).
• Recréer évite les bizarreries héritées (trous, flags de compression, CoW). Le swap n’est pas une chose unique ; traitez-le comme remplaçable.
• chmod 600 empêche les fuites et évite que swapon se plaigne ou refuse dans des environnements plus stricts.
• mkswap écrit l’en-tête de swap. Sans cela, le noyau ne sait pas ce que doit être le fichier.

Quand utiliser dd à la place

Si vous êtes sur un système de fichiers où fallocate produit un fichier plutôt sparse, échoue, ou génère des extents étranges, utilisez dd pour forcer l’allocation. C’est plus lent, mais honnête.

cr0x@server:~$ sudo rm -f /swapfile
cr0x@server:~$ sudo dd if=/dev/zero of=/swapfile bs=1M count=8192 status=progress
8589934592 bytes (8.6 GB, 8.0 GiB) copied, 9 s, 954 MB/s
8192+0 records in
8192+0 records out
8589934592 bytes (8.6 GB, 8.0 GiB) copied, 9.00726 s, 953 MB/s
cr0x@server:~$ sudo chmod 600 /swapfile
cr0x@server:~$ sudo mkswap /swapfile
Setting up swapspace version 1, size = 8 GiB (8589930496 bytes)
no label, UUID=52b75f13-10bd-4b0a-89c7-92b9c2aa9916
cr0x@server:~$ sudo swapon /swapfile

Règle de décision : Si filefrag montre un nombre ridicule d’extents, ou si l’activation se plaint de trous, recréez avec dd ou déplacez le swapfile sur un système de fichiers mieux adapté.

Blague #2 : Un swapfile sparse, c’est comme un câble d’alimentation « sans fil » — techniquement ça existe, mais ce n’est pas ce que vous vouliez.

Sécurité : permissions et où vont les données du swap

Le swap peut contenir des extraits de tout : des clés privées TLS en mémoire, des tokens de session, des identifiants en clair qui ont vécu un milliseconde de trop dans un buffer. Votre swapfile doit appartenir à root et être en mode 0600. Ce n’est pas de la paranoïa. C’est du concret.

Si votre disque est chiffré (LUKS), le swap hérite de cette protection quand il vit dans le volume chiffré. S’il n’est pas chiffré et que vous traitez des données sensibles, repensez le modèle de menace. « Ce n’est que du swap » est la phrase qui vous amène à expliquer à la conformité pourquoi du contenu mémoire a été récupérable sur un disque mis hors service.

fstab : entrées, ordre et pièges

Le swap qui ne se met pas au démarrage est du swap que vous n’avez pas. Pour les serveurs, j’aime /etc/fstab parce que c’est explicite et audit-able. Vous pouvez aussi utiliser des unités systemd de swap, mais vous finirez par les déboguer avec les mêmes primitives.

Une bonne entrée fstab pour swapfile

cr0x@server:~$ sudo sh -c 'printf "%s\n" "/swapfile none swap sw,pri=10 0 0" >> /etc/fstab'
cr0x@server:~$ tail -n 3 /etc/fstab
# swap was on /dev/sda3 during installation
/swapfile none swap sw,pri=10 0 0

Signification : Le système activera /swapfile au démarrage avec la priorité 10.

Décision : Choisissez une priorité intentionnellement. Si vous avez plusieurs zones de swap, la priorité décide laquelle est utilisée en premier (et si le noyau stripe).

Pièges courants de fstab qui font perdre des heures

• Mauvais chemin : vous avez créé /swapfile mais écrit /swap.img.
• Espaces ou caractères cachés : un copier/coller depuis un chat peut ajouter des espaces insécables. Oui, je l’ai vu.
• Swapfile sur un point de montage qui arrive tard : si /swapfile vit sur un autre système de fichiers qui échoue à monter, le swap ne s’activera pas. Cette erreur peut être silencieuse à moins de lire les logs de démarrage.
• Supposer que fstab implique succès : il implique une tentative. Vérifiez avec swapon --show après le démarrage.

Vérifier si systemd l’a réellement activé

cr0x@server:~$ systemctl status swapfile.swap --no-pager
Unit swapfile.swap could not be found.

Signification : Vous n’avez pas d’unité explicite nommée swapfile.swap. Avec fstab, systemd génère des unités dynamiquement ; le nom dépend de l’encodage du chemin.

Décision : Ne poursuivez pas les noms d’unités en premier. Confirmez l’activation via swapon, puis inspectez les unités générées si nécessaire :

cr0x@server:~$ systemctl list-units --type=swap --all --no-pager
  UNIT           LOAD   ACTIVE SUB    DESCRIPTION
  dev-zram0.swap loaded active active /dev/zram0
  swapfile.swap  loaded active active /swapfile

LOAD   = Reflects whether the unit definition was loaded.
ACTIVE = The high-level unit activation state.
SUB    = The low-level unit activation state.

Décision : Si l’unité de swap est manquante ou a échoué, inspectez les logs de démarrage et les propriétés du swapfile plutôt que de bricoler la swappiness comme mécanisme palliatif.

Priorité du swap : ce que ça fait et comment l’utiliser

La priorité est l’endroit où le « ça marche sur mon laptop » devient un comportement serveur déroutant. Linux utilise la priorité de swap pour décider des zones de swap à allouer. Une priorité plus élevée est utilisée en premier. Les zones de même priorité peuvent être utilisées de manière équilibrée (pensez : répartir les E/S), ce qui peut être bien si vous avez plusieurs dispositifs aussi rapides, et très mauvais si vous stripez accidentellement un NVMe rapide et un vieux HDD lent.

Schémas pratiques de priorité

• zram en premier (priorité élevée) : utilisez le swap compressé en RAM pour absorber de brèves pressions sans toucher au disque.
• swap disque rapide en second : swapfile/partition NVMe comme niveau suivant.
• swap disque lent en dernier (ou jamais) : le swap sur HDD peut maintenir le noyau en vie, mais il punira la latence.

Définir la priorité dans fstab

Exemple : préférer zram, puis swapfile.

cr0x@server:~$ sudo sed -i 's#^/swapfile .*#\/swapfile none swap sw,pri=10 0 0#' /etc/fstab
cr0x@server:~$ sudo swapoff /swapfile
cr0x@server:~$ sudo swapon /swapfile
cr0x@server:~$ swapon --show --output=NAME,SIZE,PRIO
NAME      SIZE PRIO
/dev/zram0   2G  100
/swapfile    8G   10

Décision : Si vous voyez des priorités égales entre des périphériques hétérogènes, corrigez cela. La prévisibilité vaut mieux que le striping accidentel.

Savoir ce que signifie « priority -2 »

Quand vous lancez swapon sans spécifier de priorité, le noyau assigne une valeur par défaut. Les partitions de swap obtiennent souvent une priorité par défaut plus élevée que les swapfiles selon la façon dont elles sont activées. Cela compte quand vous avez les deux et pensez que « le nouveau swapfile » est pris en compte — alors que le système continue de marteler l’ancienne partition de swap.

cr0x@server:~$ swapon --show --output=NAME,TYPE,SIZE,USED,PRIO
/dev/sda2 partition  4G  1.2G   -1
/swapfile  file       8G  128M   -2

Décision : Si vous voulez que le swapfile soit préféré, définissez pri supérieur à la partition (ou désactivez la partition). Ne supposez pas.

Pièges spécifiques aux systèmes de fichiers (ext4, XFS, Btrfs, ZFS)

C’est là que résident la plupart des « gotchas » du swapfile. Le sous-système de swap a besoin d’un mappage de blocs stable. Certains systèmes de fichiers aiment déplacer des blocs pour de bonnes raisons (copy-on-write, défragmentation, reflinks). Le swap n’apprécie pas ces fantaisies.

ext4 : le défaut pour une raison

Les swapfiles ext4 sont généralement sûrs. Vos principaux risques :

• Créer un fichier sparse (commun lorsqu’on utilise truncate ou certains comportements de fallocate sur des configurations étranges).
• Placer le swap sur un système de fichiers fortement fragmenté (plus pénible sur HDD que sur SSD).
• Mauvaises permissions ou oubli de mkswap.

XFS : aussi fiable

Les swapfiles sur XFS sont généralement corrects. Comme pour ext4, assurez-vous que le fichier est correctement alloué et que les permissions sont correctes. XFS est largement utilisé en production, et les swapfiles n’y sont pas exotiques.

Btrfs : possible, mais arrêtez d’improviser

Btrfs a des fonctionnalités qui entrent en conflit avec le swap : copy-on-write, compression, et mappage d’extents potentiellement dynamique. Les noyaux modernes peuvent supporter les swapfiles sur Btrfs, mais seulement si le swapfile respecte des contraintes (pas de CoW, pas compressé, et correctement alloué). Si vous ne comprenez pas ces contraintes, vous créerez un swapfile qui s’active aujourd’hui et échouera après un defrag ou un balance.

Contrôles de sanity à exécuter si le swapfile est sur Btrfs :

cr0x@server:~$ findmnt -no FSTYPE,TARGET /swapfile
btrfs /
cr0x@server:~$ lsattr /swapfile
---------------------- /swapfile

Signification : Les attributs de fichier ici ne montrent pas NOCOW (C). C’est suspect sur Btrfs.

Décision : Pour un swapfile sur Btrfs, vous voulez généralement NOCOW. Une méthode courante consiste à le définir sur le fichier puis à allouer. Si vous avez déjà écrit des données, vous devrez peut-être recréer. Flux d’exemple :

cr0x@server:~$ sudo swapoff /swapfile
cr0x@server:~$ sudo rm -f /swapfile
cr0x@server:~$ sudo truncate -s 0 /swapfile
cr0x@server:~$ sudo chattr +C /swapfile
cr0x@server:~$ sudo fallocate -l 8G /swapfile
cr0x@server:~$ sudo chmod 600 /swapfile
cr0x@server:~$ sudo mkswap /swapfile
Setting up swapspace version 1, size = 8 GiB (8589930496 bytes)
no label, UUID=0e1c4a2d-5d8d-4c08-a5c8-40db51b4dfc3
cr0x@server:~$ sudo swapon /swapfile

À surveiller : Si swapon renvoie « Invalid argument » ou se plaint de trous, les extents du fichier ne sont pas acceptables. Ne forcez pas ; déplacez le swap vers une partition de swap ou un système de fichiers non-CoW.

ZFS : le swapfile est généralement le mauvais outil

Sur ZFS, les swapfiles sont notoirement délicats car ZFS est copy-on-write et ne fournit pas les mêmes garanties que le swap attend. Beaucoup d’opérateurs utilisent une partition de swap dédiée ou un zvol pour le swap. Si vous exécutez Debian sur ZFS root, votre plan « swapfile sur dataset ZFS » peut devenir un piège de performance et de fiabilité.

Conseils pragmatiques :

• Si vous êtes sur ZFS et que vous voulez du swap, préférez une partition de swap dédiée ou un zvol configuré correctement.
• Si vous devez absolument utiliser un swapfile, testez soigneusement sous pression mémoire, confirmez qu’aucune snapshot/recordsize/compression ne vous nuit, et attendez-vous à des surprises désagréables.

Tuning performance et fiabilité (ce qui compte, ce qui ne compte pas)

La performance du swap dépend principalement de la latence du stockage et d’éviter le swapping pathologique. Un swapfile parfaitement réglé sur un stockage lent reste un stockage lent. Votre objectif n’est pas « ne jamais swapper ». Votre objectif est « rester vivant et réactif pendant la pression attendue ».

Swappiness : politique, pas magie

La swappiness par défaut (souvent 60) convient aux systèmes à usage général. La réduire peut diminuer le swapping mais augmenter la pression sur le cache de pages et provoquer d’autres modes d’échec (comme un OOM plus tôt selon certains motifs). L’augmenter peut garder plus de cache hors de la RAM, mais pousser plus tôt des pages anonymes hors mémoire, ce qui peut nuire à la latence interactive.

cr0x@server:~$ sudo sysctl -w vm.swappiness=20
vm.swappiness = 20
cr0x@server:~$ sudo sh -c 'printf "%s\n" "vm.swappiness=20" > /etc/sysctl.d/99-swappiness.conf'
cr0x@server:~$ sysctl vm.swappiness
vm.swappiness = 20

Décision : Changez la swappiness seulement après avoir vérifié que le swap est correctement configuré et que vous pouvez reproduire le profil de charge. Sinon, vous changez juste la façon dont le système échoue.

À quoi ressemble le “swap thrash”

Le thrash, c’est quand le système passe plus de temps à déplacer des pages qu’à faire du travail utile. Symptômes :

• La charge moyenne monte tandis que l’IDLE CPU reste non nul mais l’iowait explose.
• La réponse interactive devient de l’ordre de secondes à minutes.
• vmstat montre un swap-in/out soutenu.
• La latence disque augmente ; la profondeur des files d’attente aussi.

cr0x@server:~$ cat /proc/pressure/memory
some avg10=0.25 avg60=0.18 avg300=0.10 total=48239210
full avg10=0.07 avg60=0.05 avg300=0.02 total=10293829

Signification : PSI (Pressure Stall Information) montre le temps pendant lequel les tâches sont bloquées en attente de mémoire. « full » indique des blocages suffisamment sévères pour empêcher tout progrès.

Décision : Si « full » est non négligeable en fonctionnement normal, vous êtes sous-dimensionné ou mal configuré. Traitez-le comme un problème de capacité ou de charge, pas comme un simple problème de formatage du swapfile.

Priorités et médias mixtes : ne stripez pas NVMe avec HDD

Si vous mettez la même priorité sur un swap rapide et un swap lent, le noyau peut répartir les E/S de swap sur les deux. Cela tire le stockage rapide au rythme du lent et introduit de la gigue. Définissez des priorités pour que le périphérique lent ne soit qu’un dernier recours, ou désactivez-le complètement sauf si vous en avez besoin comme tampon OOM.

Taille : « combien de swap ai-je besoin ? »

Les règles empiriques sont dangereuses car les charges varient. Pourtant, en production j’utilise des tailles pratiques :

• Serveurs généraux : 2–8 GiB de swap suffisent souvent comme filet de sécurité si vous avez assez de RAM.
• Runners de build/test et hôtes Java lourds : un swap plus grand peut gagner du temps pendant les pics, mais surveillez la latence.
• Hibernation : le swap doit accueillir l’image d’hibernation (souvent proche de la taille RAM, parfois moins avec compression, mais ne pas jouer la roulette).

En cas de doute : dimensionnez le swap pour gérer un pic court et empêcher un panic/OOM du noyau, pas pour rendre un système sous-dimensionné « correct ».

Trois mini-récits d’entreprise issus des tranchées du swapfile

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

Une entreprise de taille moyenne exploitait Debian sur une flotte de workers CI. Ils standardisèrent une étape de durcissement « swapfile 8G partout ». Quelqu’un écrivit un script d’automatisation qui faisait : créer le fichier, lancer mkswap, ajouter au fstab, terminé. Ça fonctionnait en staging. Ça fonctionnait en production… parfois. Le « parfois » est la source des incidents.

Les workers avaient un mélange de systèmes de fichiers parce que le parc avait une personnalité : les nœuds plus anciens étaient en ext4 ; les plus récents en Btrfs car quelqu’un voulait des snapshots. L’automatisation ne détectait pas le type de système de fichiers. Sur les nœuds Btrfs, le swapfile existait mais l’activation échouait sur certains démarrages et réussissait sur d’autres après des opérations de maintenance. Les symptômes étaient incohérents : certains nœuds allaient bien, d’autres déclenchaient soudainement des OOM-kill de builds aux heures de pointe.

La mauvaise hypothèse était simple : « un swapfile est un swapfile. » Ce n’est pas le cas. Le comportement du système de fichiers compte, surtout le copy-on-write et les sémantiques de defrag. L’équipe perdit une journée à chasser un « comportement kernel aléatoire » et des « fuites mémoire JDK » avant que quelqu’un ne compare swapon --show entre nœuds et remarque que la moitié de la flotte n’avait pas de swap actif.

La correction fut ennuyeuse et décisive : détecter Btrfs, créer une partition de swap dédiée pour ces hôtes (ou configurer correctement Btrfs avec NOCOW et recréer), et ajouter une vérification au démarrage qui alerte si le swap n’est pas actif. L’incident ne tenait pas à la taille du swap ; il tenait à l’absence du filet de sécurité.

Mini-récit 2 : l’optimisation qui se retourne contre vous

Une équipe fintech avait une API sensible à la latence. Quelqu’un lut que le swap cause de la latence, ce qui est vrai de la même façon que le feu cause de la chaleur. Ils mirent vm.swappiness=1 sur toute la flotte et réduisirent la taille du swap à presque zéro. Les métriques semblaient excellentes — jusqu’à ce qu’un déploiement introduise une légère augmentation mémoire.

En charge normale, les services fonctionnaient. En pointe, la pression mémoire monta, le cache de fichiers ne put être suffisamment récupéré, et le noyau commença à tuer des processus OOM au lieu d’échanger des pages froides. L’« optimisation » transforma une dégradation progressive en un précipice : les requêtes s’arrêtèrent, les pods redémarrèrent, et l’équipe connut une panne en cascade classique amplifiée par les retries.

Ils avaient optimisé pour le chemin heureux et supprimé le tampon pour le chemin malheureux. Le plus frustrant : l’incident n’était même pas une énorme fuite mémoire. C’était une nouvelle fonctionnalité plus un pic de trafic plus l’absence du filet de sécurité.

Ils rétablirent une swappiness sensée, restaurèrent la capacité de swap, et introduisirent une politique : réduire le swapping en corrigeant l’utilisation mémoire, pas en désactivant le swap. Le swap redevint ce qu’il doit être : ce qui vous achète du temps pour intervenir, pas ce qui masque un sous-dimensionnement chronique.

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

Une équipe plateforme interne d’une entreprise exploitait Debian 13 sur un ensemble de workers stateful. Ils firent une chose ennuyeuse que peu d’équipes priorisent : un script de vérification au démarrage qui vérifiait l’activation du swap et consignait une erreur claire si elle n’était pas présente. C’était dans leur vérification de « readiness » du nœud, juste à côté du contrôle d’espace disque et de la sanity NTP.

Pendant un cycle de mise à jour du noyau, un sous-ensemble de nœuds cessa d’activer le swap après le reboot. La raison n’était pas glamour : un changement de stockage modifia l’ordre de montage, et le chemin du swapfile devint temporairement indisponible au moment où systemd essayait de l’activer. Personne ne le remarqua immédiatement — sauf la vérification de readiness, qui signala les nœuds comme non sains et empêcha les workloads d’y être planifiés.

Cela empêcha un incident proprement dit. L’équipe eut le temps d’inspecter journalctl, d’ajuster l’ordre (et dans quelques cas de relocaliser le swap), et de réintroduire les nœuds progressivement. Les utilisateurs ne surent rien. La direction ne se demanda jamais pourquoi les graphiques de latence ressemblaient à un sismographe. C’était le genre de succès discret qu’on n’obtient qu’avec des contrôles ennuyeux.

La leçon : le swap ne concerne pas que la performance ; il concerne l’exploitabilité. Un système prévisible bat un système ingénieux.

Erreurs courantes : symptôme → cause racine → correction

Cette section est la carte « je veux juste que ce soit réparé ». Chaque erreur est spécifique, reproductible, et suffisamment commune pour mériter une cicatrice.

1) Le swapfile existe mais n’apparaît pas dans swapon

Symptôme : ls /swapfile montre le fichier, mais swapon --show est vide ou le manque.

Cause racine : Swap non activé (fstab absent/erroné) ou activation échouée au démarrage.

Correction : Exécutez sudo mkswap /swapfile (si nécessaire) puis sudo swapon /swapfile. Ajoutez une entrée correcte dans /etc/fstab et confirmez après redémarrage.

2) swapon échoue avec « Operation not permitted » ou « permission denied »

Symptôme : sudo swapon /swapfile renvoie une erreur.

Cause racine : Permissions non 0600, mauvais propriétaire, ou enforcement d’une politique de sécurité.

Correction : sudo chown root:root /swapfile && sudo chmod 600 /swapfile, puis réessayez.

3) swapon échoue avec « Invalid argument » sur Btrfs

Symptôme : L’activation échoue malgré des permissions correctes.

Cause racine : Swapfile sur Btrfs avec CoW/compression ou extents/trous non supportés.

Correction : Recréez le swapfile avec NOCOW (chattr +C avant allocation), assurez-vous qu’il n’est pas compressé, ou utilisez une partition de swap/zvol.

4) Le système démarre, mais le swap manque parfois après reboot

Symptôme : Swap présent certains démarrages, absent d’autres.

Cause racine : Course/ordre : le swapfile est sur un système de fichiers non monté quand l’activation du swap s’exécute ; ou la maintenance du système de fichiers a modifié le mapping d’extents.

Correction : Mettez le swap sur la racine ou assurez-vous que le point de montage sous-jacent est stable tôt ; vérifiez les dépendances des unités systemd de swap ; envisagez une partition de swap pour la fiabilité.

5) Un swapping intense cause une latence ×10 et des timeouts

Symptôme : Le temps de réponse explose ; vmstat montre un si/so soutenu ; iowait monte.

Cause racine : L’ensemble de travail ne tient pas en RAM ; swap sur stockage lent ; ou sur-engagement mémoire dû à la concurrence.

Correction : Réduisez l’empreinte mémoire ou la concurrence, ajoutez de la RAM, déplacez le swap sur un média plus rapide, et considérez le swap comme tampon d’urgence plutôt que substitut permanent de RAM.

6) Le swap est utilisé, mais la mauvaise zone est utilisée en premier

Symptôme : Vous avez ajouté un swapfile NVMe rapide mais le système continue de swapper sur une partition HDD.

Cause racine : Les priorités favorisent la partition, ou des priorités égales provoquent un striping entre les deux.

Correction : Définissez explicitement pri= dans fstab ou via swapon -p pour préférer le swap rapide, et rétrogradez/désactivez le swap lent.

7) L’hibernation échoue après le passage à un swapfile

Symptôme : La reprise échoue ; le système démarre à froid.

Cause racine : La configuration de resume n’est pas mise à jour pour le swapfile offset ; le swapfile a été déplacé/changé d’extents.

Correction : Calculez l’offset de reprise correct et mettez à jour la configuration d’initramfs adéquatement, ou utilisez une partition de swap dédiée pour la stabilité de l’hibernation.

8) « Pas de swap » était intentionnel, et maintenant vous avez des kills OOM

Symptôme : Des processus sont tués lors de pics ; le système est instable.

Cause racine : Supprimer le swap a retiré votre tampon ; les pics mémoire sont maintenant fatals.

Correction : Réintroduisez un swap modeste (et surveillez), puis corrigez l’utilisation mémoire et redimensionnez les hôtes.

Checklists / plan pas-à-pas

Plan A : Serveur Debian 13 standard sur ext4/XFS (swapfile)

1. Confirmer le système de fichiers : findmnt -no FSTYPE,TARGET /swapfile. Si ext4/XFS, continuez.
2. Choisir la taille : commencez par 4–8 GiB sauf besoin connu (hibernation ou pics très importants).
3. Créer le swapfile : fallocate -l 8G /swapfile.
4. Définir les permissions : chmod 600 /swapfile ; vérifiez avec ls -l.
5. Initialiser : mkswap /swapfile.
6. Activer maintenant : swapon /swapfile ; vérifiez avec swapon --show.
7. Rendre persistant : ajoutez /swapfile none swap sw,pri=10 0 0 dans /etc/fstab.
8. Test de reboot : redémarrez pendant une fenêtre de maintenance ; vérifiez que le swap est actif après le démarrage.
9. Surveiller : suivez l’utilisation du swap, PSI mémoire, et les événements OOM ; alertez quand l’utilisation du swap grimpe ou que la pression « full » est non nulle pendant des périodes prolongées.

Plan B : racine Btrfs (swapfile seulement si vous maîtrisez les contraintes)

1. Décidez si une partition de swap est plus simple : pour beaucoup de systèmes de production, c’est le cas.
2. Si vous utilisez un swapfile : créez le fichier avec NOCOW avant d’allouer les blocs.
3. Assurez-vous d’aucune compression : ne stockez pas le swapfile sur un sous-volume/dataset compressé.
4. Recréez plutôt que modifier : traitez le swapfile comme immuable. Si vous changez les attributs après écriture, vous demandez des ennuis.
5. Vérifiez l’activation maintenant et après reboot : si c’est instable, arrêtez et changez d’approche.

Plan C : zones de swap multiples (zram + swap disque)

1. Décidez de l’ordre de priorité : zram le plus haut ; NVMe ensuite ; HDD en dernier.
2. Définissez explicitement les priorités : ne comptez pas sur les valeurs par défaut.
3. Vérifiez l’ordre effectif : swapon --show --output=NAME,PRIO.
4. Testez en charge mémoire : prouvez que le système se dégrade de façon graduelle et n’entre pas en thrash.

FAQ

1) Dois-je utiliser une partition de swap ou un swapfile sur Debian 13 ?

Sur ext4/XFS : le swapfile convient et est plus facile à redimensionner. Si vous avez besoin d’une hibernation fiable ou si vous êtes sur des systèmes de fichiers délicats (notamment Btrfs/ZFS), une partition (ou un zvol sur ZFS) est souvent le choix le plus sûr.

2) Quelles permissions pour un swapfile ?

0600, appartenant à root. Autre chose constitue un risque d’exposition de données et peut aussi causer des échecs d’activation selon la politique.

3) Pourquoi mon swapfile affiche la priorité -2 ?

C’est une priorité assignée par défaut quand vous n’en spécifiez pas. Ce n’est pas automatiquement faux. Cela devient problématique quand vous avez plusieurs zones de swap et que vous tenez à l’ordre d’utilisation.

4) Est-ce que fallocate est toujours sûr pour les swapfiles ?

Généralement sûr sur ext4/XFS. Pas universellement sûr sur tous les systèmes de fichiers et configurations. Si l’activation se plaint de trous ou si le fichier est étrangement fragmenté, recréez avec dd ou déplacez le swap sur un système de fichiers plus simple.

5) Comment savoir si le swap nuit à la performance ?

Cherchez un swap-in/out soutenu (vmstat), un iowait croissant (iostat), et une augmentation de la pression mémoire « full » (PSI). Si la latence de réponse augmente en parallèle, vous êtes en thrash.

6) Puis-je mettre un swapfile sur Btrfs ?

Oui, mais seulement si vous respectez les contraintes (pas de CoW, pas de compression, allocation stable). Si vous ne pouvez pas garantir cela, utilisez une partition de swap. La fiabilité vaut mieux que la nouveauté.

7) Quelle taille pour mon swapfile sur des serveurs ?

Généralement 4–8 GiB comme filet de sécurité, puis ajustez selon les pics observés et l’historique d’incidents. Si vous avez besoin d’hibernation, dimensionnez-le explicitement pour ce cas d’usage.

8) Dois-je régler vm.swappiness à 1 pour la performance ?

Pas par défaut. Cela peut réduire le swapping, mais aussi augmenter le risque d’OOM lors de pics. Ajustez en fonction des preuves issues de la charge, pas des légendes web.

9) Pourquoi le swap ne s’active pas au démarrage alors que fstab est correct ?

Souvent l’ordre de montage : le swapfile se trouve sur un système de fichiers qui n’est pas disponible quand l’activation du swap s’exécute. Vérifiez les logs de démarrage et les unités de swap générées par systemd, et envisagez de relocaliser le swap.

10) zram remplace-t-il le swap disque ?

C’est un complément. zram est excellent pour absorber de courts pics rapidement. Sous pression soutenue, vous pouvez encore avoir besoin d’un swap disque — ou de plus de RAM — selon la charge.

Conclusion : étapes suivantes qui réduisent vraiment le risque

Si vous exploitez Debian 13 en production, considérez le swap comme un élément de conception système, pas une case à cocher. Vos prochaines étapes sont simples et pratiques :

1. Auditez l’état du swap à l’échelle de la flotte : confirmez que le swap est activé, que les priorités sont intentionnelles, et que l’activation est cohérente entre les redémarrages.
2. Corrigez la justesse d’abord : permissions 0600, allocation non sparse, et adéquation du système de fichiers.
3. Rendez le comportement au démarrage déterministe : fstab (ou unités systemd explicites), plus une vérification de santé qui alerte quand le swap manque.
4. Mesurez la pression mémoire : utilisez vmstat, PSI et les logs pour les événements OOM ; ne comptez pas sur les plaintes utilisateurs pour la surveillance.
5. Utilisez la priorité pour éviter les surprises : gardez le swap rapide rapide, et réservez le lent comme dernier recours si vous le conservez.

Le swap ne corrigera pas une fuite mémoire. Il gardera cependant vos systèmes debout assez longtemps pour que vous puissiez réparer le vrai problème. C’est un compromis que je choisis volontiers.