Débogage de mémoire insuffisante avec / var / log / messages

42

Le rapport suivant est jeté dans mon journal de messages:

kernel: Out of memory: Kill process 9163 (mysqld) score 511 or sacrifice child
kernel: Killed process 9163, UID 27, (mysqld) total-vm:2457368kB, anon-rss:816780kB, file-rss:4kB

Peu importe si ce problème est pour httpd, mysqldou postfixje suis curieux de savoir comment puis-je continuer à résoudre le problème.

Comment puis-je obtenir plus d'informations sur la raison pour laquelle le PID 9163 est tué et je ne suis pas sûr que Linux garde l'historique des PID terminés quelque part.

Si cela se produit dans votre fichier journal de messages, comment allez-vous résoudre ce problème étape par étape?

# free -m

             total       used       free     shared    buffers     cached
Mem:          1655        934        721          0         10         52
-/+ buffers/cache:        871        784
Swap:          109          6        103`

— Ibedelovski
source

Dans quoi tous les messages sur le problème apparaissent-ils dmesg?

— Stark07

Détails utiles sur OOM - linux-mm.org/OOM_Killer .

— slm

57

Le noyau aura consigné beaucoup de choses avant que cela se produise, mais la plupart d'entre elles ne seront probablement pas insérées /var/log/messages, selon la (r)syslogdconfiguration de votre configuration. Essayer:

grep oom /var/log/*
grep total_vm /var/log/*

Les premiers devraient apparaître plusieurs fois et les derniers à un ou deux endroits seulement. C'est le fichier que vous voulez regarder.

Recherchez la ligne d'origine "Mémoire insuffisante" dans l'un des fichiers contenant également total_vm. Trente seconde à une minute (pourrait être plus, pourrait être moins) avant cette ligne, vous trouverez quelque chose comme:

kernel: foobar invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0

Vous devriez également trouver un tableau quelque part entre cette ligne et la ligne "Mémoire insuffisante" avec des en-têtes comme celui-ci:

[ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name

Cela ne vous en dit peut-être pas plus que ce que vous savez déjà, mais les champs sont les suivants:

pid L'identifiant du processus.
uid ID utilisateur.
tgid ID du groupe de discussion.
total_vm utilisation de la mémoire virtuelle (en pages de 4 ko)
rss Utilisation de la mémoire des résidents (en pages de 4 Ko)
nr_ptes Entrées de table de page
swapents Entrées swap
oom_score_adj Habituellement 0; un nombre inférieur indique que le processus risque moins de mourir lorsque le tueur de MOO est appelé.

Vous pouvez principalement ignorer nr_pteset swapentsmême si je crois que ce sont des facteurs pour déterminer qui sera tué. Ce n'est pas nécessairement le processus qui utilise le plus de mémoire, mais très probablement. Pour plus d'informations sur le processus de sélection, voir ici . En gros, le processus qui aboutit au score le plus élevé est éliminé - c'est le "score" indiqué sur la ligne "Mémoire insuffisante"; Malheureusement, les autres scores ne sont pas rapportés, mais ce tableau fournit des indices en termes de facteurs.

Encore une fois, cela ne fera probablement pas beaucoup plus qu'éclairer l'évidence: le système a manqué de mémoire et a mysqldété choisi pour mourir car il le libérerait le plus de ressources . Cela ne signifie pas nécessairement que vous mysqldfaites quelque chose de mal. Vous pouvez consulter le tableau pour voir si quelque chose d'autre a dépassé les bornes à ce moment-là, mais il se peut qu'il ne reste aucun coupable: le système peut manquer de mémoire simplement parce que vous avez mal évalué ou mal configuré les processus en cours.

— boucle d'or
source

5

dmesgest où cela est garanti pour être. Il ne sera présent que /var/logsi le démon syslog lit /dev/kmsg(ce qui est généralement le cas).

— Patrick

2

@ Patrick Cela dépend du moment où vous allez regarder. S'il est enregistré dans l'un des journaux de fichiers normaux (cela devrait être, ou si vous avez fait quelque chose de stupide avec votre enregistreur), il sera là pendant longtemps, alors qu'à ce stade, si le PO veut diagnostiquer un problème qui s'est produit hier ou la veille, etc., il se peut que l'enregistrement ne soit dmesgplus disponible même si le système était en cours d'exécution.

— goldilocks

6

La clé de ceci est dans le message lui-même - Plus de mémoire . Quand le noyau Linux est privé de mémoire virtuelle (RAM physique plus swap), il commence à tuer les processus et c'est exactement ce qui s'est passé ici. Il semble mysqldutiliser plus de 2 Go de mémoire virtuelle.

Combien de RAM et d'échange le système a-t-il? J'envisagerais d'ajouter de la RAM supplémentaire ou, si ce n'est pas possible, d'ajouter un échange supplémentaire. Pour résoudre au moins le problème de l’arrêt des processus, vous pouvez ajouter un fichier d'échange.

Mise à jour: En regardant la quantité de RAM dont vous disposez, vous pouvez immédiatement voir le problème. Vous avez ~ 1,6 Go de RAM et 100 Mo d’échange, mais MySQL utilise beaucoup plus de RAM que cela. Cela explique pourquoi vous voyez des processus en cours de fin.

— mjturner
source

total       used       free     shared    buffers     cached Mem:          1655        934        721          0         10         52  -/+ buffers/cache:        871        784 Swap:          109          6        103

c'est la sortie mémoire en même temps que le processus a été tué

— ibedelovski

Pouvez-vous peut-être coller cela dans le message d'origine, en conservant la mise en forme? Cela rendrait la lecture plus facile.

— Mjturner

Je ne suis pas très bon en formatage ... mais je le colle déjà dans le message d'origine

— ibedelovski