Réglage du killere OOM Linux pour les VPS

Le Linux OOM killer est le dernier recours du noyau lorsque la mémoire vient à manquer : il sélectionne un processus et le termine pour maintenir le système en vie. Sur un VPS, où la RAM est limitée et où il n'y a pas de solution de repli, le choix par défaut est souvent le mauvais. Votre base de données est tuée, un processus de fond qui tourne depuis longtemps survit, et vous devez vous débrouiller pour comprendre pourquoi. Ce guide explique comment l'OOM killer évalue les processus, comment orienter cette évaluation vers vos services critiques, et comment utiliser les cgroups pour qu'un seul processus incontrôlable ne puisse pas entraîner le reste du système dans sa chute.

Comment l'OOM killer choisit une victime

Lorsque le noyau ne parvient pas à récupérer suffisamment de mémoire via l'éviction du cache de pages ou l'espace d'échange, il invoque l'OOM killer. Chaque processus a un oom_score score compris entre 0 et 1000, dérivé principalement de sa taille de mémoire résidente (RSS) et de son utilisation de l'espace d'échange. Le processus ayant le score le plus élevé reçoit un SIGKILL.

La RSS domine le calcul, c'est pourquoi le kill touche presque toujours le plus gros consommateur de mémoire. Il s'agit souvent de votre base de données, de votre serveur d'applications ou de tout autre processus de longue durée effectuant le travail le plus utile. Le processus qui a réellement déclenché l'allocation, l'« invoker », est rarement celui qui est arrêté.

Il existe deux types d'événements OOM qu'il convient de distinguer :

• OOM global : l'hôte (ou votre VPS dans son ensemble) est à court de RAM et d'espace d'échange. Le noyau analyse chaque processus et tue celui qui a le score le plus élevé.
• OOM cgroup : un cgroup spécifique a atteint sa limite de mémoire. Le noyau ne tue que les processus au sein de ce cgroup, même si le reste du système dispose de mémoire disponible.

Si vous avez configuré des limites d'unité systemd ou si vous exécutez des conteneurs, la plupart de vos événements OOM seront des OOM de cgroup. C'est une bonne chose : le rayon d'action est limité.

Détecter la pression sur la mémoire avant la panne

Les événements OOM ne sont presque jamais soudains. Il y a généralement une période pendant laquelle la pression augmente, et l'objectif de la surveillance est de la détecter pendant cette période.

free -h vous donne une vue d'ensemble du système. La colonne qui importe est available, et non free: elle correspond au cache de pages récupérable et reflète ce que vous pouvez réellement allouer sans recourir au swap. Maintenez MemAvailable environ 10 à 15 % MemTotal en période de charge maximale.

Pour une attribution par processus, triez par RSS :

ps aux --sort=-%mem | head -10

Ou utilisez htop et triez par RES. Les valeurs que vous voyez ici alimentent directement le système de notation du noyau, de sorte que les entrées en tête de liste sont les cibles les plus susceptibles de subir un OOM.

Sur les noyaux 4.20 et plus récents, les informations de blocage sous pression constituent un système d'alerte précoce qu'il vaut la peine d'intégrer à la surveillance :

cat /proc/pressure/memory

Le some avg10 figure représente le pourcentage de temps pendant lequel au moins une tâche a été bloquée en attente de mémoire au cours des dix dernières secondes. Une valeur inférieure à 5 % est acceptable. Des valeurs supérieures à 10 % de manière soutenue signifient que le système passe du temps réel bloqué sur la récupération de mémoire, et un arrêt OOM est plausible.

Le swap thrashing apparaît dans vmstat 1 sous la forme de valeurs non nulles si et so qui se maintiennent dans le temps. Une faible quantité de swap résident est inoffensive. Des opérations de swap-in et de swap-out constantes ne le sont pas.

Protéger les processus critiques avec oom_score_adj

Le score calculé par le noyau peut être ajusté pour chaque processus via oom_score_adj, sur une échelle allant de -1000 (immunisé) à +1000 (tuez-moi en premier). L'ajustement est ajouté directement au score final.

Pour une modification ponctuelle sur un processus en cours d’exécution :

echo -500 | sudo tee /proc/$(pidof sshd)/oom_score_adj

Pour tout ce que vous souhaitez conserver après les redémarrages, configurez-le dans l'unité systemd. C'est l'endroit idéal pour sshd, votre base de données et tout ce que vous ne pouvez pas vous permettre de perdre :

[Service]
OOMScoreAdjust=-900

Valeurs par défaut raisonnables pour commencer :

• sshd : -1000. Si vous perdez l'accès à distance lors d'une crise de mémoire, la récupération devient beaucoup plus difficile.
• MySQL, PostgreSQL, Redis : -800 à -900. Une protection solide sans les rendre totalement intouchables dans une situation véritablement catastrophique.
• Workers d'application, tâches batch, tâches cron : +100 à +500. Ce sont les processus que vous préférez voir s'arrêter plutôt que votre base de données.

Ne réglez pas tout sur -1000. Si rien ne peut être tué, le noyau finira par paniquer ou se bloquer, ce qui est pire.

Limiter la mémoire avec les cgroups et systemd

L'ajustement des scores influence le choix des processus à tuer. Les cgroups déterminent si le kill global a lieu ou non. En attribuant à chaque service une limite supérieure stricte, vous concentrez les défaillances de mémoire dans un seul cgroup plutôt que de laisser un seul processus épuiser l'ensemble du VPS.

Dans un fichier d'unité systemd :

[Service]
MemoryHigh=400M
MemoryMax=512M
OOMPolicy=stop
Restart=on-failure
RestartSec=5s

MemoryHigh est un limiteur souple : le noyau récupère agressivement des pages du cgroup au-delà de ce seuil, mais ne tue rien. MemoryMax est le plafond strict. Si le cgroup tente d'allouer au-delà de cette limite, le noyau tue un processus à l'intérieur du cgroup. Avec Restart=on-failure le service redémarre immédiatement.

Sur cgroup v2 (Ubuntu 22.04 et versions ultérieures, Debian récente, RHEL 9), memory.oom.group tous les processus du cgroup sont tués ensemble au lieu de laisser des processus orphelins. Utile pour les services multiprocessus comme les pools PHP-FPM où un groupe partiellement tué se comporterait de manière anormale.

Quelques remarques spécifiques à certaines applications qui méritent d'être prises en compte :

• PHP-FPM : configurez pm = ondemand sur les petites instances VPS et dimensionnez pm.max_children en fonction de la valeur RSS moyenne par worker, et non de la valeur par défaut. Un pool dimensionné pour 4 Go de marge sur un VPS de 2 Go provoquera une erreur OOM dès qu'il sera plein.
• Node.js : limitez le tas V8 avec --max-old-space-size=512 (en Mo). Sans cela, Node continuera de croître jusqu’à ce que le noyau intervienne.
• MySQL et PostgreSQL : innodb_buffer_pool_size et shared_buffers devraient laisser une marge suffisante pour le cache de pages du système d'exploitation, la mémoire de connexion et tout autre locataire sur la machine. Les valeurs par défaut supposent un serveur dédié.

Lecture des journaux après un événement OOM

Lorsque le OOM killer se déclenche, le noyau enregistre un rapport détaillé dans le tampon circulaire. Récupérez-le avec :

dmesg -T | grep -iE 'killed process|out of memory'
journalctl -k --grep='Out of memory'

Le bloc à lire attentivement commence par l'invoker et se termine par la victime. Le noyau affiche une liste complète des tâches avec le RSS de chaque processus, l'utilisation de l'espace d'échange et la mémoire finale oom_score_adj. Trois éléments méritent d'être vérifiés :

• La contrainte. CONSTRAINT_NONE signifie un OOM global, CONSTRAINT_MEMCG signifie qu’un cgroup a atteint sa limite. La solution diffère selon le cas.
• Free swap. Si c'est 0kB, cela signifie que la RAM et l'espace d'échange sont épuisés. Il faut soit ajouter de l'espace d'échange, soit augmenter MemoryMax sur le coupable, ou réduisez la concurrence.
• Le score de la victime par rapport à tous les autres. Si le score de la victime n'est pas beaucoup plus élevé que celui des processus suivants, vos oom_score_adj valeurs ne sont pas suffisantes. Élargissez l'écart.

Pour les OOM de cgroup en particulier, le compteur de kill se trouve memory.events à l'intérieur du cgroup :

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

Une augmentation du oom_kill signifie que le service atteint sa limite de manière répétée. C'est le signal qu'il faut augmenter MemoryMax, d'analyser la charge de travail ou de faire passer le service à un plan plus important, et non de le redémarrer en boucle.

En conclusion

Régler l'OOM killer ne consiste pas à le faire disparaître. Il s'agit de contrôler quel processus en fait les frais lorsque la mémoire vient à manquer, et de réduire l'ampleur des dégâts lorsque cela se produit. La règle qui s'applique en production :

• Protégez les services que vous ne pouvez pas vous permettre de perdre, en particulier sshd et vos bases de données.
• Limitez tout le reste avec MemoryMax dans une unité systemd afin qu'un seul processus déchaîné n'entraîne qu'un simple redémarrage, et non une panne.
• Surveillez le PSI et MemAvailable plutôt que d’attendre dmesg de vous informer a posteriori.
• Prévoyez 15 à 20 % de RAM en marge. L'optimisation ne peut pas compenser un VPS qui est tout simplement trop petit pour la charge de travail.

Si votre pression sur la mémoire est structurelle plutôt que configurable, vous avez besoin de plus de RAM ou d'un stockage sur swap plus rapide. Les offres VPS de FDC Servers fonctionnent sur AMD EPYC avec un stockage NVMe, ce qui maintient les lectures sur swap suffisamment rapides pour que les pics de mémoire de courte durée ne se transforment pas en arrêts.