Le service « a disparu ». Pas de stack Java propre, parfois pas de core. systemctl montre failed ou un redémarrage, code de sortie 9 (SIGKILL) ou 137 en conteneur (128+9). L’application n’a pas eu le temps de logger : KILL n’est pas rattrapable. Si vous cherchez l’exception dans le log applicatif, vous cherchez au mauvais étage.
sudo dmesg -T | grep -i 'out of memory\|killed process'
journalctl -k -b | grep -i oomLe noyau écrit qu’il a invoqué l’OOM killer, le nom du processus, le oom_score, parfois la liste des RSS. C’est la preuve. Sans cette ligne, un exit 9 peut être un kill -9 humain ou un orchestrateur.
Sur systemd : OOMKilled= dans systemctl show, ou le résultat de systemd-analyze / le status. Sous cgroup v2 (conteneurs, slices), l’OOM peut être celui du cgroup, pas celui de la machine : memory.oom.group, événements dans memory.events. La machine a encore de la RAM libre et le pod meurt : c’est un plafond memory.max, pas « Linux n’a plus de mémoire ».
Le score (oom_score_adj) favorise les gros consommateurs ajustables. Un processus oom_score_adj=-1000 est protégé ; une JVM sans limite dans un cgroup de 512 Mo n’est pas « leaky », elle est mal bornée. Distinguer fuite, pic légitime, limite trop basse est tout l’entretien.
Ajouter de la RAM en première réponse. D’abord : qui a été tué, quelle limite (machine vs cgroup), quelle tendance (free -h, si/so si on swappe — le swap retarde l’OOM et crée de la latence, la machine « rampe » avant de tuer). Puis : fuite (pmap, heap dump), workers trop nombreux, cache page vs RSS. Un available bas avec un cache page énorme n’est pas le même tableau qu’un RSS applicatif qui a tout mangé : le cache se rend, le heap Java non.
Distinguer aussi un OOM du runtime (JVM OutOfMemoryError dans le log applicatif, process encore là) d’un OOM noyau. Le premier se soigne dans l’appli (-Xmx, fuite). Le second a déjà tué le process. Les candidats mélangent les deux mots ; les séparer est déjà une bonne réponse.
« Comment empêcher que ça retue le même service ? »
Plafond de mémoire au bon niveau (unité MemoryMax=, cgroup, requêtes K8s), Restart= qui ne masque pas la cause, et correction du consommateur. vm.overcommit et oom_kill_allocating_task sont des leviers de noyau, pas un rustine de prod sans mesure. La phrase attendue : preuve dans le journal noyau, puis quelle mémoire (laquelle), puis qui a décidé de la limite.