Lire la pression mémoire sous Linux : free, swap, OOM killer et OOMScoreAdjust

Ce que c'est

free affiche la mémoire totale, utilisée, libre, partagée, le buff/cache et la mémoire disponible, ainsi qu'une ligne pour le swap. La colonne free seule sous-estime la marge réelle, car Linux utilise la mémoire par ailleurs inactive comme cache disque ; la colonne available estime la quantité de mémoire qui peut réellement être attribuée à un nouveau processus sans recourir au swap, en tenant compte du cache récupérable. Lorsque la mémoire disponible et le swap sont tous deux épuisés, l'OOM killer (out-of-memory) du noyau choisit un processus à tuer pour que le système continue de fonctionner, et consigne son action dans le journal du noyau, consultable avec dmesg ou journalctl -k.

Deux paramètres d'unité systemd permettent d'agir sur ce mécanisme service par service : OOMScoreAdjust=, une valeur comprise entre -1000 et 1000 écrite dans /proc/[pid]/oom_score_adj, qui oriente l'heuristique OOM du noyau pour ou contre l'arrêt du processus (plus la valeur est négative, moins il a de chances d'être choisi) ; et MemoryMax=, une limite stricte appliquée par le contrôleur cgroup, qui fait tuer un processus dépassant son propre budget avant même que l'OOM killer global n'ait à départager des services sans rapport entre eux.

Pourquoi c'est important

Un service qui s'arrête sans erreur au niveau applicatif et sans journal de crash est un symptôme courant d'un arrêt par l'OOM killer : le noyau le termine avec SIGKILL, que l'application ne peut ni intercepter ni journaliser. Confondre ce cas avec un bogue applicatif fait perdre du temps de débogage ; confondre la mémoire free avec la mémoire available conduit à de fausses alertes ou à des alertes manquées.

Comment l'appliquer

• Lisez free -h et fondez-vous sur available, pas sur free ; une petite valeur de free associée à une grande valeur de available est normale et ne pose pas de problème.
• Vérifiez l'utilisation du swap, et même si un swap est configuré (swapon --show) ; un système sans swap laisse moins de temps d'avertissement avant l'intervention de l'OOM killer.
• Après la mort inexpliquée d'un service, cherchez dans journalctl -k | grep -i "out of memory" ou dmesg | grep -i oom une trace d'arrêt indiquant le processus concerné et son score.
• Définissez OOMScoreAdjust=-500 (ou une valeur voisine) dans la section [Service] d'une unité systemd pour un processus qui doit être le dernier à être tué, et une valeur positive pour une tâche batch jetable qui doit être tuée en premier.
• Définissez MemoryMax= pour les services dont la consommation mémoire maximale est connue, afin qu'une fuite dans l'un d'eux ne puisse pas priver de mémoire les autres services du même hôte ; vérifiez avec systemctl show <unit> -p MemoryMax -p OOMScoreAdjust.

Pièges

• Traiter chaque mort de processus comme un bogue de code avant d'avoir consulté le journal du noyau à la recherche d'une trace OOM.
• Définir OOMScoreAdjust=-1000 (le service devient en pratique insensible à l'OOM killer) sur un service dont une véritable fuite mémoire passe alors inaperçue, l'arrêt étant reporté sur un autre processus au lieu de faire apparaître le problème.
• Oublier que MemoryMax= déclenche un arrêt OOM au niveau du cgroup sur les propres processus du service ; dans dmesg, il apparaît exactement comme un arrêt OOM global, mais sa cause est différente et plus circonscrite.