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
, mysqld
ou postfix
je 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`
linux
logs
memory
out-of-memory
Ibedelovski
la source
la source
dmesg
?Réponses:
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)syslogd
configuration de votre configuration. Essayer: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: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:
Cela ne vous en dit peut-être pas plus que ce que vous savez déjà, mais les champs sont les suivants:
Vous pouvez principalement ignorer
nr_ptes
etswapents
mê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 vousmysqld
faites 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.la source
dmesg
est où cela est garanti pour être. Il ne sera présent que/var/log
si le démon syslog lit/dev/kmsg
(ce qui est généralement le cas).dmesg
plus disponible même si le système était en cours d'exécution.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
mysqld
utiliser 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.
la 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é