Lire la charge moyenne (load average) et comprendre l'OOM killer

Ce que c'est

Les trois premiers champs de /proc/loadavg sont, selon proc_loadavg(5), le nombre de tâches dans la file d'exécution (état R) ou en attente d'E/S disque (état D), moyennées sur 1, 5 et 15 minutes. Ce nombre n'est pas un pourcentage : il n'a de sens que rapporté au nombre de CPU (nproc). Comme les tâches à l'état D comptent, un montage NFS bloqué ou un disque saturé fait monter la charge alors que les CPU restent inactifs.

La documentation mémoire du noyau décrit l'autre moitié. Linux surengage la mémoire par défaut (vm.overcommit_memory à 0 : les surengagements évidents sont refusés, tout le reste est accordé). Lorsqu'une allocation échoue et que la récupération ne peut pas libérer suffisamment, l'OOM killer parcourt la liste des tâches et tue celle dont le score de nuisance (badness) est le plus élevé, normalement le plus gros consommateur de mémoire, sauf si oom_kill_allocating_task est activé, auquel cas c'est la tâche à l'origine de la condition qui est tuée. proc_pid_oom_score_adj(5) explique que /proc/<pid>/oom_score_adj décale le score dans la plage -1000 (OOM_SCORE_ADJ_MIN, jamais tuée) à +1000.

Pourquoi c'est important

Ces deux chiffres sont mal interprétés en permanence. Une charge de 8 sur un hôte à 8 CPU correspond à une utilisation complète, sur un hôte à 2 CPU c'est une mise en file d'attente sévère, et dans les deux cas il peut s'agir de disque, pas de CPU. Une exécution de l'OOM killer supprime le plus gros processus, qui est généralement le service principal et non l'assistant qui fuit, et ne laisse qu'une ligne de journal noyau comme preuve.

Comment l'appliquer

• Comparer la charge avec nproc, puis distinguer la cause : vmstat 1 montre les colonnes r et b ainsi que l'inactivité CPU ; b (bloqué) avec un CPU inactif signale des E/S ; top montre les processus à l'état D.
• Après une exécution supposée de l'OOM killer, lire dmesg -T ou journalctl -k à la recherche de « Out of memory: Killed process » ; avec oom_dump_tasks à sa valeur par défaut de 1, le journal liste aussi chaque tâche avec son oom_score_adj et ses tailles mémoire à cet instant.
• Protéger le service principal avec OOMScoreAdjust=-500 ou une valeur similaire dans son unité systemd, et donner une valeur positive aux tâches par lots ; mieux encore, borner la tâche par lots avec MemoryMax= afin qu'elle soit tuée dans son propre cgroup en premier.
• Surveiller MemAvailable dans /proc/meminfo, pas « free », car le cache de pages est récupérable.

Pièges

Mettre -1000 sur tout ce qui est important déplace simplement la mise à mort vers ce qui reste, éventuellement sshd. overcommit_memory=2 (la politique « jamais de surengagement ») déplace l'échec vers le moment de l'allocation, où de nombreux programmes gèrent mal un code d'erreur de retour, et refuse les grandes demandes de précaution que, selon la documentation du noyau, de nombreux programmes font. Une charge moyenne dominée par des tâches à l'état D ne réagit pas à l'ajout de CPU.

Quand c'est le service principal qui grossit

Sur un hôte à vocation unique, le plus gros processus est généralement celui qui fuit, et un oom_score_adj fortement négatif sur celui-ci fait en sorte que le noyau tue tout le reste en premier pendant que la fuite se poursuit. Borner aussi le service principal : MemoryMax= dans son unité, fixé en dessous de la mémoire physique avec de la marge pour le système et les assistants, afin qu'une condition de manque de mémoire soit résolue dans le propre cgroup du service et se termine par un redémarrage (Restart=on-failure) plutôt que par la perte de sshd ou de l'agent de supervision. MemoryHigh= légèrement en dessous du maximum freine en premier et apparaît dans les métriques, ce qui transforme une mise à mort surprise en avertissement. Garder l'ajustement négatif modeste, et réserver -1000 à ce qui ne peut pas grossir.