J'ai un petit serveur privé virtuel fonctionnant sous CentOS et www/mail/db, qui a récemment connu quelques incidents où le serveur web et ssh ne répondaient plus.
En regardant les journaux, j'ai vu que oom-killer avait tué ces processus, peut-être à cause d'un manque de mémoire et de swap.
Quelqu'un peut-il me donner des indications sur la manière de diagnostiquer ce qui a pu causer l'incident le plus récent ? Est-il probable que ce soit le premier processus tué ? Où dois-je chercher ?
Non, l'algorithme n'est pas aussi simpliste. Vous pouvez trouver plus d'informations dans :
http://linux-mm.org/OOM_Killer
Si vous voulez suivre l'utilisation de la mémoire, je vous recommande d'exécuter une commande comme :
ps -e -o pid,user,cpu,size,rss,cmd --sort -size,-rss | headCela vous donnera une liste des processus qui utilisent le plus de mémoire (et qui sont probablement à l'origine de la situation d'OOM). Supprimez les | head si vous préférez vérifier tous les processus.
Si vous mettez cette opération sur votre cron, répétez-la toutes les 5 minutes et enregistrez-la dans un fichier. Gardez-le au moins deux jours, afin de pouvoir vérifier ce qui s'est passé plus tard.
Pour les services critiques comme ssh, je recommande d'utiliser monit pour les redémarrer automatiquement dans une telle situation. Cela pourrait vous éviter de perdre l'accès à la machine si vous n'avez pas de console à distance.
Bonne chance,
João Miguel Neves
J'ai eu du mal avec cela récemment, parce que le ou les processus sur lesquels le tueur d'oom s'acharne ne sont pas nécessairement ceux qui ont mal tourné. En essayant de diagnostiquer cela, j'ai appris l'existence d'un de mes outils préférés, atop.
Cet utilitaire est comme une toupie sur des stéroïdes. Sur un intervalle de temps prédéfini, il établit le profil des informations système. Vous pouvez ensuite les réécouter pour voir ce qui se passe. Il met en évidence les processus dont l'utilisation est supérieure à 80 % en bleu et supérieure à 90 % en rouge. La vue la plus utile est un tableau d'utilisation de la mémoire indiquant la quantité de mémoire allouée au cours de la dernière période. C'est celle qui m'a le plus aidé.
Un outil fantastique - je ne peux pas en dire assez à son sujet.
Este article sur l'apprivoisement des oom-kille r semble particulièrement utile. Il semble que l'on puisse définir des priorités pour empêcher oom-killer de tuer certains processus (sshd serait un bon début pour un VPS !).
L'OOM ne tue que le processus qui utilise le plus de mémoire à ce moment-là. Pas nécessairement le processus qui a dépassé la limite ou qui a déclenché l'appel OOm.
De plus, linux est laxiste avec son allocation de mémoire. Ainsi, si votre processus a besoin de 5 Go mais n'en utilise que 3, linux laissera un autre processus utiliser les 2 qu'il n'utilise pas. performance>fiabilité. ensuite, lorsque p1 a besoin de ses 5 Go, il ne peut pas les obtenir.
Ce n'est pas une exception. Je suis juste confronté à ce problème et j'ai trouvé ce que j'ai trouvé.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
