Comment diagnostiquer les causes des processus de destruction des tueurs d'OOM


9

J'ai un petit serveur privé virtuel exécutant CentOS et www / mail / db, qui a récemment eu quelques incidents où le serveur Web et ssh ne répondaient plus.

En regardant les journaux, j'ai vu que le tueur à gages avait tué ces processus, peut-être en raison d'un manque de mémoire et d'un échange.

Quelqu'un peut-il me donner des conseils sur la façon de diagnostiquer ce qui a pu causer l'incident le plus récent? Est-ce probablement le premier processus tué? Où dois-je chercher ailleurs?

Réponses:


11

Non, l'algorithme n'est pas si simpliste. Vous pouvez trouver plus d'informations dans:

http://linux-mm.org/OOM_Killer

Si vous souhaitez 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 | head

Il vous donnera une liste des processus qui utilisent le plus de mémoire (et qui provoquent probablement la situation de MOO). Supprimez le | headsi vous préférez vérifier tous les processus.

Si vous mettez cela sur votre cron, répétez-le toutes les 5 minutes et enregistrez-le dans un fichier. Gardez au moins quelques jours, afin que vous puissiez vérifier ce qui s'est passé plus tard.

Pour les services critiques comme ssh, je recommanderais 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 ne disposez pas d'une console distante.

Bonne chance,
João Miguel Neves


Merci - enfin, je me suis mis à essayer ceci après quelques incidents de tueur à gages qui ont mis mon serveur à genoux. Besoin de rechercher la cause.
dunxd

6

J'ai eu du mal avec ça récemment, parce que le ou les processus sur lesquels le tueur à gages piétine ne sont pas nécessairement ceux qui ont mal tourné. Tout en essayant de diagnostiquer cela, j'ai découvert l'un de mes outils désormais préférés, au sommet.

Cet utilitaire est comme un top sur les stéroïdes. Sur un intervalle de temps prédéfini, il profile les informations système. Vous pouvez ensuite le lire pour voir ce qui se passe. Il met en évidence les processus qui sont 80% + en bleu et 90% + en rouge. La vue la plus utile est une table d'utilisation de la mémoire indiquant la quantité de mémoire allouée au cours de la dernière période. C'est celui qui m'a le plus aidé.

Outil fantastique - je ne peux pas en dire assez.

au sommet du moniteur de performances



1

OOM ne fait que tuer le processus qui utilise le plus de mémoire à ce moment. Pas nécessairement le processus qui a dépassé la limite ou augmenté l'appel OOm.
Linux est également laxiste avec son allocation de mémoire. AKA si votre processus a besoin de 5 Go mais n'utilise que 3, linux permettra à un autre processus d'utiliser le 2 qu'il n'utilise pas. performance> fiabilité. puis quand p1 a besoin de son plein 5, il ne peut pas l'obtenir

Pas un exeprt. juste faire face à cela moi-même et ce que j'ai trouvé

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.