SSH admin Linux : accès distant et bonnes pratiques
29 janvier 2026NTP Linux : synchroniser l’heure sur un serveur Linux
29 janvier 2026Administration serveur Linux · Debian & Ubuntu
OOM Killer Linux : comprendre et éviter les crashes mémoire
Un processus tué sans message d’erreur clair ? C’est souvent l’OOM Killer. Comment le repérer, comprendre son fonctionnement et éviter qu’il ne cible le mauvais service.
Un service qui s’arrête brutalement, sans crash visible ni message d’erreur applicatif, est souvent la victime de l’OOM Killer (« Out-Of-Memory Killer ») : un mécanisme du noyau Linux qui tue un processus pour éviter que le serveur ne se bloque complètement quand la mémoire est épuisée. Ce guide explique comment le détecter, comprendre sa logique de sélection, et réduire le risque qu’il frappe vos services critiques.
- Qu’est-ce que l’OOM Killer ?
- Repérer un OOM kill dans les logs
- Comment le noyau choisit sa victime (oom_score)
- Protéger un service critique
- Prévenir les crashes mémoire
Qu’est-ce que l’OOM Killer ?
Quand la mémoire disponible (RAM + swap) est totalement épuisée, Linux ne peut plus allouer de mémoire à aucun processus — y compris ceux qui en ont besoin pour continuer à fonctionner normalement. Plutôt que de laisser le système se figer complètement, le noyau déclenche l’OOM Killer : il choisit un processus à sacrifier (SIGKILL) pour libérer immédiatement de la mémoire. C’est une protection du système dans son ensemble, pas un bug.
Repérer un OOM kill dans les logs
Un service qui disparaît sans laisser de trace applicative est le premier indice. Vérifiez les journaux noyau :
sudo dmesg | grep -i 'killed process'
sudo journalctl -k | grep -i oomUn OOM kill produit une ligne caractéristique du type Out of memory: Killed process 1234 (mysqld) total-vm:..., avec le nom et le PID du processus sacrifié.
Si un service redémarre tout seul sans explication apparente, vérifiez toujours dmesg avant de chercher un bug applicatif : c’est souvent l’OOM Killer, pas le programme lui-même, qui est en cause.
Comment le noyau choisit sa victime
Chaque processus se voit attribuer un oom_score, recalculé dynamiquement, qui reflète à quel point il est « candidat » à être tué — principalement en fonction de sa consommation mémoire. Le processus avec le score le plus élevé est sacrifié en premier. Vous pouvez consulter ce score :
cat /proc/<PID>/oom_scoreProtéger un service critique
Il est possible d’ajuster manuellement la probabilité qu’un processus soit choisi, via oom_score_adj (de -1000, jamais tué, à +1000, tué en priorité) :
# Rendre un processus beaucoup moins susceptible d'être tué :
echo -500 | sudo tee /proc/<PID>/oom_score_adjPour un service géré par systemd, intégrez directement le réglage dans son unité :
[Service]
OOMScoreAdjust=-500Ne mettez jamais -1000 (protection absolue) sur un service quelconque : si la mémoire est totalement épuisée et qu’aucun processus n’est éligible, le noyau peut se retrouver dans une situation encore plus instable. Réservez cette protection maximale aux processus vraiment critiques (comme sshd).
Prévenir les crashes mémoire
- Dimensionnez correctement la RAM par rapport aux services réellement hébergés — la cause la plus fréquente reste simplement un serveur sous-dimensionné.
- Surveillez la mémoire régulièrement avec
free -h,vmstat 1ouhtoppour repérer une tendance avant qu’elle ne devienne critique. - Configurez un swap raisonnable : il ne remplace pas la RAM mais donne une marge de manœuvre avant que l’OOM Killer n’intervienne.
- Envisagez
systemd-oomd(inclus sur les distributions récentes) : il intervient de manière plus précoce et prévisible que l’OOM Killer du noyau, en surveillant la pression mémoire (PSI) plutôt que d’attendre l’épuisement total. - Limitez la mémoire d’un service gourmand via systemd (
MemoryMax=dans l’unité) pour qu’il échoue proprement plutôt que d’entraîner tout le système dans sa chute.
FAQ — OOM Killer
L’OOM Killer est-il un signe de bug du système ?
Non, c’est un mécanisme de protection normal. Le vrai problème sous-jacent est presque toujours un manque de mémoire par rapport à la charge — fuite mémoire applicative, service mal dimensionné, ou pic de charge inattendu.
Désactiver l’OOM Killer est-il une bonne idée ?
Non. Sans lui, un épuisement mémoire peut totalement figer le serveur au lieu de sacrifier un seul processus. Mieux vaut ajuster oom_score_adj pour protéger les services critiques plutôt que de le désactiver.
Quelle différence entre l’OOM Killer du noyau et systemd-oomd ?
L’OOM Killer du noyau agit en dernier recours, quand la mémoire est déjà totalement épuisée. systemd-oomd surveille la pression mémoire en amont et peut intervenir plus tôt et de façon plus prévisible.
Conclusion
L’OOM Killer n’est pas une panne mais une protection : comprendre ses logs et son fonctionnement permet de réagir vite (identifier le vrai problème de mémoire) et d’éviter qu’il ne cible vos services les plus importants grâce à oom_score_adj. La véritable solution reste toujours de surveiller et dimensionner correctement la mémoire du serveur.
