Configurer le swap et éviter les plantages par manque de mémoire

Le service a disparu. Aucun rapport de plantage, aucun stacktrace, le fichier journal s'arrête au milieu d'une ligne. MariaDB ne répond plus, nginx renvoie une 502, le serveur Minecraft est hors ligne, et l'application elle-même n'affiche rien d'anormal. Le schéma est presque toujours le même : le noyau n'avait plus de mémoire libre et a tué un processus pour garder le système en vie. Cet article montre comment le prouver sans le moindre doute, comment créer proprement un fichier swap et l'inscrire de façon permanente, et dans quels cas le swap ne fait que repousser le problème de quelques minutes.

Établir la preuve : dmesg et journalctl

Avant de configurer quoi que ce soit, il vous faut la preuve. À chaque OOM kill (Out of Memory), le noyau écrit un bloc détaillé dans le tampon circulaire :

dmesg -T | grep -iE 'out of memory|oom-kill'

Si aucune ligne ne remonte et que la commande se termine avec le code de sortie 1, il n'y a pas eu d'OOM noyau depuis le dernier démarrage. Ce code de sortie n'est pas une erreur, c'est simplement la réponse habituelle de grep quand il ne trouve rien. Si quelque chose remonte, cela ressemble à ceci sur les quatre systèmes traités ici :

mariadbd invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=0
oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/mariadb.service,task=mariadbd,pid=1043,uid=107
Out of memory: Killed process 1043 (mariadbd) total-vm:2894760kB, anon-rss:1583204kB, file-rss:0kB, shmem-rss:0kB, UID:107 pgtables:3820kB oom_score_adj:0

Trois éléments comptent ici. Premièrement : invoked oom-killer désigne le processus qui a demandé la mémoire, pas forcément le coupable. Deuxièmement : le processus tué figure sur la ligne Killed process. Troisièmement : la valeur déterminante est anon-rss, c'est-à-dire la mémoire anonyme réellement occupée. total-vm correspond à l'espace d'adressage réservé, régulièrement plusieurs fois plus élevé avec Java ou Go, et cette valeur ne signifie rien.

Lancé sans les droits root, dmesg répond sur Debian 12, Debian 13, Ubuntu 22.04 et Ubuntu 24.04 par dmesg: read kernel buffer failed: Operation not permitted, parce que kernel.dmesg_restrict vaut partout 1. Travaillez donc avec sudo ou en root. Si le message persiste même en root, vous êtes dans un conteneur (container) LXC ou OpenVZ, qui n'a aucun accès au tampon circulaire du système hôte. Seule la seconde voie, via journalctl -k, permet alors d'avancer.

Après un redémarrage, le tampon circulaire est vide. D'où la seconde voie par le journal, et c'est là que se cache le piège que la plupart des tutoriels laissent de côté :

journalctl -k --grep "Out of memory"

-k implique -b et n'affiche donc que le démarrage en cours. Si la machine a redémarré après l'incident, cette commande ne renvoie rien alors même que l'événement a bien été journalisé. Pour le démarrage précédent ou pour une période donnée :

journalctl -k -b -1 --grep "Out of memory"

journalctl --since "7 days ago" --grep "Out of memory|oom-kill"

Si la première des deux commandes répond No journal boot entry found for the specified boot (-1), c'est qu'aucun démarrage antérieur n'est enregistré dans le journal. Là encore, ce n'est pas une erreur mais le cas normal sur un système dont le journal n'écrit que depuis le démarrage actuel.

Tout cela ne fonctionne que si le journal est réellement persistant. Vérifiez-le :

ls -d /var/log/journal

Sur Debian et Ubuntu, ce répertoire existe d'origine : le test aboutit donc presque toujours, et le mkdir qui suit tourne à vide sans rien casser. Si par exception le répertoire n'existe pas, le journal ne réside que dans /run et disparaît à chaque redémarrage. Deux commandes suffisent à rattraper cela :

mkdir -p /var/log/journal

systemctl restart systemd-journald

OOM noyau ou limite systemd ? Deux causes différentes

Cette distinction décide si le swap apporte quoi que ce soit. Regardez le champ constraint dans le message du noyau.

CONSTRAINT_NONE signifie : c'est le système entier qui s'est retrouvé à court de mémoire. Là, le swap aide.

CONSTRAINT_MEMCG signifie : un seul control group a dépassé sa limite, alors que le reste du système avait de la marge. Là, le swap ne sert à rien, il faut relever la limite ou rendre l'application plus économe. Ce type de kill se repère aussi au niveau du service lui-même :

systemctl status mariadb

Si vous y lisez Main process exited, code=killed, status=9/KILL et, plus bas, Failed with result 'oom-kill', il s'agissait bien d'un OOM kill. Un fichier compteur révèle si une limite cgroup était en jeu. Il suppose cgroup v2, la norme sur les quatre distributions ; avec l'ancien cgroup v1, le chemin n'existe pas :

cat /sys/fs/cgroup/system.slice/mariadb.service/memory.events

systemctl show mariadb -p MemoryMax -p MemoryHigh

Une valeur supérieure à zéro pour oom_kill, combinée à un MemoryMax défini, prouve l'existence d'une limite locale.

Il existe un troisième candidat, souvent oublié parce qu'il n'écrit rien du tout dans dmesg : systemd-oomd. Ce service travaille en espace utilisateur, exploite l'indicateur de pression PSI et arrête des control groups entiers avant même que le noyau n'intervienne. Son message dans le journal ressemble à Killed /system.slice/... due to memory pressure for /system.slice being 60.00% > 50.00% for > 20s with reclaim activity. Vérifiez s'il tourne :

systemctl is-active systemd-oomd

Sur Ubuntu, systemd-oomd est installé et actif d'origine depuis la 22.04 ; sur Debian, il ne fait pas partie de l'installation standard. Un inactive sur un serveur Debian est donc attendu et ne signale aucune erreur.

À retenir pour la suite : systemd-oomd peut aussi se déclencher parce que le swap se remplit. Avec oomd actif, ajouter du swap peut donc provoquer les arrêts plus tôt au lieu de les retarder.

Avant le swap : quelle quantité de mémoire manque vraiment

Deux minutes de mesure évitent une mauvaise décision.

free -h

Seule la colonne available est intéressante, pas free. Le cache compte comme disponible et sera libéré en cas de besoin. Qui lit la colonne free croit surchargé n'importe quel système en bonne santé.

ps -eo pid,comm,rss,%mem --sort=-rss | head -n 11

systemd-cgtop --order=memory -b -n 1

La première commande montre les plus gros processus isolés, la seconde regroupe par service. En pratique, on y retrouve presque toujours les trois mêmes suspects : MariaDB avec un innodb_buffer_pool_size choisi trop grand, PHP-FPM avec un pm.max_children trop élevé et une JVM avec un -Xmx trop généreux.

Pour dimensionner le fichier swap au départ, ce tableau suffit. Sur un serveur, plus gros ne veut pas dire mieux, car un swap que vous utilisez réellement en totalité rend la machine inutilisable.

Créer le fichier swap

Commencez par regarder s'il existe déjà du swap. Les serveurs Ubuntu installés depuis l'ISO embarquent souvent déjà /swap.img, Debian issu de son installateur plutôt une vraie partition de swap. Les images cloud des deux distributions n'ont en règle générale rien du tout.

swapon --show

Si la sortie reste vide, il n'y a pas de swap. Vérifiez ensuite le système de fichiers, car la marche à suivre en dépend :

findmnt -no FSTYPE -T /

Avec ext4 ou xfs, vous pouvez continuer directement. Créez le fichier avec dd, pas avec fallocate. fallocate va plus vite, mais selon le système de fichiers et le noyau il produit un fichier comportant des zones non écrites, que swapon refuse ensuite. dd écrit de vrais zéros et fonctionne partout :

dd if=/dev/zero of=/swapfile bs=1M count=2048 status=progress

chmod 600 /swapfile

Avant l'étape suivante, une vérification vaut la peine, et beaucoup la sautent. Si un swap déjà activé se trouve sous /swapfile, par exemple à cause d'un essai antérieur ou du préréglage de l'image, mkswap refuse de travailler avec mkswap: error: /swapfile is mounted; will not make swapspace. Seul compte ici le fait que le chemin soit listé comme actif dans /proc/swaps. Regardez donc, et désactivez si nécessaire :

swapon --show

swapoff /swapfile

Si swapon --show n'affiche aucune ligne contenant /swapfile, vous pouvez sauter le swapoff. Écrivez ensuite la zone de swap :

mkswap /swapfile

mkswap répond Setting up swapspace version 1, size = 2 GiB (2147479552 bytes) suivi d'un nouvel UUID. Ce n'est qu'après cela que l'on active :

swapon /swapfile

L'ordre n'est pas négociable. chmod avant mkswap, mkswap avant swapon, et un éventuel swapoff avant tout le reste.

Comment savoir que cela a vraiment fonctionné

Le fait que swapon se termine sans message d'erreur ne prouve encore rien. Ce sont ces deux sorties qui font foi :

swapon --show

free -h

swapon --show doit sortir une ligne avec /swapfile, file, la taille et une priorité. Dans free -h, la ligne Swap: doit être passée de 0B à la nouvelle taille. Si l'une des deux sorties reste inchangée, le swap n'est pas actif, quoi qu'ait annoncé la commande auparavant.

Rendre le swap permanent sans risquer le démarrage

Un swapon ne survit pas à un redémarrage. L'entrée a sa place dans /etc/fstab, et c'est précisément là que les serveurs se cassent. Sauvegardez d'abord :

cp /etc/fstab /etc/fstab.bak

echo '/swapfile none swap sw 0 0' >> /etc/fstab

Faites attention aux deux signes supérieurs. Un seul > écrase tout le fichier, et la machine ne démarre alors plus correctement. Vérifiez ensuite la syntaxe avant de redémarrer :

findmnt --verify

Un avertissement est ici parfaitement normal et n'est pas une raison pour retirer la ligne : [W] non-bind mount source /swapfile is a directory or regular file. C'est inévitable avec un fichier swap, et la commande se termine malgré tout avec le code de retour 0. Si le fichier n'a en plus pas d'en-tête de swap valide, [W] cannot detect on-disk filesystem type s'y ajoute, et là vous avez effectivement oublié un mkswap.

Si vous avez déjà activé le swap plus haut à la main avec swapon /swapfile, il est actif dès maintenant. Sinon, swapon -a active toutes les entrées de la fstab sans que vous ayez à redémarrer. Mais le vrai test est ailleurs. systemd génère une unit propre à partir de chaque ligne de la fstab ; pour /swapfile, elle s'appelle swapfile.swap. Si cette unit apparaît et qu'elle est active, le swap sera à coup sûr monté au prochain démarrage :

systemctl daemon-reload

systemctl list-units --type swap

On attend une ligne swapfile.swap loaded active active Swap. Si elle manque, la ligne de la fstab est fausse et un redémarrage se terminerait sans swap. Ce n'est qu'une fois ce point réglé que le redémarrage vaut la peine, avec un contrôle derrière via swapon --show.

Régler correctement swappiness

Le paramètre noyau vm.swappiness détermine avec quelle facilité les pages anonymes partent dans le swap plutôt que de sacrifier le cache de fichiers. Sur Debian 12, Debian 13, Ubuntu 22.04 et Ubuntu 24.04, la valeur par défaut est partout la même, à savoir 60 :

cat /proc/sys/vm/swappiness

Depuis le noyau 5.8, la plage de valeurs va de 0 à 200, et les quatre distributions embarquent un noyau plus récent. Deux idées fausses très répandues : vm.swappiness=0 ne désactive pas le swap, cela empêche seulement la mise en swap préventive, et le noyau ira quand même dans le swap avant de tuer un processus. Par ailleurs, une valeur basse n'accélère pas un système auquel la mémoire manque tout simplement.

Valeurs raisonnables : 10 à 20 sur les serveurs de bases de données, 60 sur les serveurs web mixtes, 100 et plus si vous utilisez zram. Pour que le réglage soit permanent, il va dans un fichier dédié sous /etc/sysctl.d/, et non dans /etc/sysctl.conf, qui gêne lors des mises à jour de paquets :

echo 'vm.swappiness = 10' > /etc/sysctl.d/99-swappiness.conf

sysctl --system

cat /proc/sys/vm/swappiness

La troisième commande est le contrôle de réussite. sysctl --system lit tous les répertoires dans un ordre fixe, et un fichier déjà présent portant un numéro plus élevé peut écraser votre valeur.

Quand ça tourne mal : les messages d'erreur mot pour mot

swapon: /swapfile: insecure permissions 0644, 0600 suggested. Simple avertissement, le swap fonctionne quand même. Corrigez-le tout de même, sinon n'importe quel utilisateur peut lire le contenu des processus partis en swap : chmod 600 /swapfile.

swapon: /swapfile: swapon failed: Invalid argument L'erreur la plus fréquente. Soit mkswap a été oublié, soit le fichier contient des trous. Le journal du noyau affiche alors en plus swapon: swapfile has holes. Solution : supprimer le fichier et le recréer avec dd au lieu de fallocate.

Sur btrfs, la même erreur apparaît, accompagnée de BTRFS warning: swapfile must not be copy-on-write. L'ordre des opérations est ici différent : le fichier doit être créé vide et marqué comme non copy-on-write avant d'être rempli. Une précision préalable qui peut décider du sort d'un serveur en production : truncate -s 0 et rm s'exécutent aussi lorsqu'un swap actif est encore monté sous ce chemin. Le noyau pointe ensuite vers des blocs qui n'existent plus. Si swapon --show liste le chemin comme actif, un swapoff /swapfile doit donc impérativement passer avant.

truncate -s 0 /swapfile

chattr +C /swapfile

Ensuite, remplissez comme d'habitude avec dd, puis chmod 600, mkswap, swapon. Sur les sous-volumes compressés et dans les snapshots, le swap ne fonctionne toujours pas.

swapon: /swapfile: swapon failed: Operation not permitted Vous êtes dans un conteneur. LXC, OpenVZ et Docker partagent le noyau de l'hôte et n'ont pas le droit d'activer leur propre swap. Vérification :

systemd-detect-virt

Si la commande renvoie kvm, qemu ou none, un noyau propre tourne et le swap est possible. Si elle renvoie lxc, openvz ou docker, seule une augmentation de la RAM ou un produit avec virtualisation complète peut aider. Les serveurs root KVM et les serveurs dédiés de KernelHost disposent de leur propre noyau, le swap s'y configure donc sans restriction.

dd: error writing '/swapfile': No space left on device Le stockage est trop plein. D'abord df -h, puis supprimez le fichier à moitié écrit avec rm /swapfile, sinon il continue d'occuper de la place. Là encore : si swapon --show affiche le chemin comme actif, un swapoff /swapfile doit passer avant la suppression.

Le système ne démarre plus, la console de secours apparaît. Presque toujours une faute de frappe dans /etc/fstab. Connectez-vous via la console de l'espace client, puis mount -o remount,rw /, supprimez la ligne fautive ou recopiez /etc/fstab.bak, et redémarrez. C'est exactement pour cela que la sauvegarde avait été créée au préalable.

Différences entre Debian 13, Debian 12, Ubuntu 24.04 et 22.04

Les commandes sont identiques sur les quatre systèmes, l'état de départ ne l'est pas.

• Swap existant : Ubuntu Server installé depuis l'ISO crée souvent /swap.img, Debian issu de son installateur une partition de swap. Les images cloud des deux distributions arrivent sans swap. Toujours commencer par swapon --show.
• systemd-oomd : installé et actif d'origine sur Ubuntu depuis la 22.04, absent de l'installation standard sur les deux versions de Debian. Cela explique pourquoi un logiciel identique peut mourir différemment sur deux systèmes apparemment semblables.
• Base de données : Debian 12 et Debian 13 ne fournissent pas de mysql-server, c'est toujours MariaDB qui y tourne (10.11 sous Debian 12, 11.8 sous Debian 13). Ubuntu 22.04 et 24.04 proposent les deux. Les valeurs par défaut de innodb_buffer_pool_size diffèrent en conséquence, et c'est précisément cette valeur qui constitue la cause d'OOM la plus fréquente sur les petits serveurs.
• Java : Debian 12 ne connaît qu'OpenJDK 17, Debian 13 seulement OpenJDK 21, Ubuntu 22.04 et 24.04 couvrent de 8 à 21. Une JVM sans -Xmx défini se réserve par défaut un quart de la RAM ; avec plusieurs instances, l'OOM kill est programmé d'avance.
• Messages du noyau : le format et la formulation du message OOM sont identiques sur les quatre systèmes, les exemples ci-dessus s'appliquent partout.
• swappiness : 60 par défaut partout.

Quand le swap aide et quand il ne fait que repousser le problème

Le swap aide de façon fiable lors de pics courts, par exemple pendant une sauvegarde, une mise à jour de paquets ou un import nocturne. Il aide pour les services qui occupent beaucoup de mémoire puis ne font plus rien pendant des jours, car ces pages peuvent tranquillement rester sur le stockage. Et en cas de coup dur, il vous offre quelques minutes pendant lesquelles la session SSH répond encore et où vous pouvez intervenir, au lieu de vous retrouver devant un serveur mort.

Le swap n'aide pas lorsque le besoin permanent dépasse tout simplement la RAM disponible. Le système se met alors à thrasher : il envoie sans cesse des pages dans le swap et les ramène, la load monte à deux chiffres, la charge CPU reste basse, tout attend l'I/O. En pratique, c'est pire qu'un OOM kill propre, parce que même la connexion ne passe plus. Deux commandes montrent si vous êtes dans cet état :

vmstat 1 5

test -e /proc/pressure/memory && cat /proc/pressure/memory

Avec vmstat, ce sont les colonnes si et so qui comptent. Des valeurs à trois chiffres en continu signalent des échanges permanents avec le swap. Dans /proc/pressure/memory, la valeur décisive est full avg10 : au-dessus de 10, le système entier passe dix pour cent du temps à attendre de la mémoire. Au-dessus de 40, la machine est pratiquement morte. Ce fichier n'existe toutefois que si Pressure Stall Information est actif dans le noyau. Les noyaux standard de Debian et Ubuntu l'embarquent, d'autres noyaux pas forcément. D'où la précaution avec test -e : si le fichier manque, la sortie reste vide, au lieu de vous faire prendre un No such file or directory pour un défaut. PSI peut être ajouté après coup via le paramètre de démarrage du noyau psi=1.

Cette ligne répond à la question de savoir quels processus se trouvent réellement dans le swap :

grep VmSwap /proc/*/status | sort -k2 -rn | head

Le swap ne sert à rien non plus contre une limite cgroup (CONSTRAINT_MEMCG), contre de la mémoire épinglée avec mlock et contre une JVM dont le heap est configuré plus grand que la RAM disponible. Le garbage collector parcourt régulièrement l'intégralité du heap et ramène immédiatement chaque page partie dans le swap.

Les trois outils pour le cas où le swap ne suffit pas

zram crée une zone de swap compressée directement dans la RAM. Elle est plus rapide de plusieurs ordres de grandeur qu'un fichier sur le stockage et procure, selon les données, 20 à 40 % de mémoire utile en plus :

apt update

apt install -y zram-tools

La configuration se fait dans /etc/default/zramswap via ALGO=zstd et PERCENT=50, suivi de systemctl restart zramswap. Contrôle avec zramctl puis à nouveau swapon --show, où /dev/zram0 apparaît alors. Avec zram, vm.swappiness doit monter à une valeur de 100 à 180, parce que le passage en swap y est bon marché.

earlyoom intervient avant que le noyau ne fige le système, et tue de façon ciblée plutôt que par heuristique :

apt install -y earlyoom

Dans /etc/default/earlyoom, vous définissez les seuils via EARLYOOM_ARGS et vous protégez les processus importants, par exemple avec -m 5 -s 5 --avoid '(^|/)(sshd|systemd)$'. La connexion SSH reste ainsi accessible pendant que le dévoreur de mémoire tombe.

Des limites fixes par service constituent la solution la plus propre lorsqu'un service précis déborde régulièrement. Via systemctl edit mariadb, vous inscrivez MemoryHigh=1200M et MemoryMax=1500M. Le service est alors freiné et, au besoin, arrêté seul, au lieu d'entraîner tout le serveur avec lui. Contrôle via systemctl show mariadb -p MemoryMax.

Dans la plupart des cas, le vrai correctif reste toutefois la configuration applicative : innodb_buffer_pool_size ramené à une valeur réaliste, pm.max_children calculé sur le besoin réel en mémoire par worker, un -Xmx défini pour chaque JVM. Le swap est le filet de sécurité, pas la solution.

Revenir en arrière si cela ne convient pas

Le chemin du retour est court et doit se faire dans cet ordre :

swapoff /swapfile

Si le swap est fortement occupé, la commande peut tourner plusieurs minutes, car toutes les pages doivent revenir en RAM. Si elle échoue sur swapoff: /swapfile: swapoff failed: Cannot allocate memory, la RAM n'a pas de place pour ce rapatriement et il faut d'abord arrêter des services. Ce n'est qu'après un swapoff réussi que l'on retire la ligne de la fstab et que l'on supprime le fichier :

rm /swapfile

swapon --show

Supprimer le fichier tant qu'il est encore monté conduit à un système dont la gestion de la mémoire pointe vers un inode qui n'existe plus. Cela finit mal. Pour terminer, un free -h de plus et un redémarrage en guise de contre-épreuve.