Connaissez-vous l’ « OOM-Killer » ?

Je me rappelle, il y a quelques années, je recevais environ 600 spams par jour. Et puis soudain…plus rien pendant 1 jour, 2 jours, 3 jours… Là, je me dis « c’est pas normal ! je devrais bien recevoir quelques messages tout de même ! ».

Une investigation rapide dans les logs du serveur de messagerie montrent que l’antivirus (clamd) consommant de plus en plus de mémoire a déclenché la colère de l’OOM-Killer et a provoqué l’arrêt de « postfix » !

La même mésaventure est arrivée à un de mes clients, il y a quelques jours : « Dites : vous pouvez jeter un coup d’oeil à nos batchs (crontabs) car ils ne sont pas déclenchés ?« . La syntaxe semble pourtant bonne, les jobs, lancés manuellement, fonctionnent. Oui, mais voilà, le démon crond n’existe pas, pourtant il est bien lancé au démarrage… Que s’est-il passé ? La faute à l’OOM-Killer encore une fois !

Petit rappel de la gestion de la mémoire par le noyau Linux…

Fonctionnement du noyau Linux :

Un noyau Linux peut allouer plus de mémoire qu’il n’en possède vraiment (RAM + swap) :

par exemple, lors d’un fork, il y a copie virtuelle des pages de données. Tant que les processus ne les modifient pas, elles ne sont pas dupliquées (copy on write). On peut aussi expliquer le choix du noyau Linux par l’argument suivant « je peux accepter d’allouer de la mémoire pour le processus P car je sais qu’il ne va pas l’utiliser tout de suite. Et quand il voudra l’utiliser, avec de la chance, un autre processus en aura libérée« . C’est ce qu’on nomme un algorithme « optimiste » !

Mais même en étant optimiste, il arrive que la mémoire soit saturée : le noyau doit bien tenir ses promesses !

Un algorithme appelé OOM-Killer est alors invoqué pour tuer des processus (presque pris au hasard !) et ainsi récupérer de la mémoire.

Dans les cas cités plus haut, ce choix du « processus à dézinguer » est tombé sur smtpd (postfix) et crond… Oups ! Et heureusement que ce n’est pas tombé sur sshd !

Comment modifier l’algorithme de l’OOM-Killer ?

• tout d’abord le paramètre /proc/sys/vm/panic_on_oom (0 par défaut) peut recevoir la valeur 1 : dans ce cas, la machine se met en mode « panic », mode qui se règle aussi…
• le paramètre /proc/sys/vm/overcommit_memory peut recevoir la valeur 2 pour inhiber l’algorithme d’allocation optimiste, avec le risque de saturer la mémoir plus rapidement…

Comment protéger certains processus contre l’OOM-Killer ?

• pour chaque processus, le paramètre /proc/<PID>/oom_score donne la probabilité d’être éradiqué par l’OOM-Killer. Plus basse est la valeur, plus faible est cette probabilité. La valeur 0 indique un processus qui ne sera pas tué
• pour chaque processus, le paramètre /proc/<PID>/oom_adj permet d’adjuster cette probabilité. Le paramètre prend une valeur entre -17 et +15. La valeur -17 protège le processus contre l’OOM-Killer. A votre avis, quelle est la valeur attribuée à sshd ?

Conclusion :

• Surveiller le taux d’occupation de la mémoire (RAM et swap)
• Surveiller les logs pour vérifier que l’OOM-Killer ne s’est pas déclenché