messages

Le rapport suivant est envoyé 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 mais je suis curieux comment puis-je continuer à déboguer le problème.

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

Si cela se produit dans votre file 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`

Le kernel aura enregistré un tas de choses avant que cela ne se produise, mais la plupart ne sera probablement pas dans /var/log/messages , selon la configuration de votre (r)syslogd . Essayer:

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

Le premier devrait apparaître un tas de fois et le second dans seulement un ou deux endroits. C'est le file que vous voulez regarder.

Trouvez la ligne originale "Mémoire total_vm " dans l'un des files qui contient également total_vm . Trente secondes à une minute (pourrait être plus, pourrait être less) avant cette ligne, vous findez quelque chose comme:

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

Vous devriez également find une table quelque part entre cette ligne et la ligne "Mémoire insuffisante" avec des en-têtes comme ceci:

 [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name

Cela peut ne pas vous en dire beaucoup plus que vous le savez déjà, mais les champs sont:

pid L'identifiant du process.
ID user uid .
tgid ID du groupe de threads.
total_vm Utilisation de la memory virtuelle (4 Ko)
rss Utilisation de la memory résidente (dans 4 Ko pages)
nr_ptes Entrées dans la table des pages
swapents Échanger des inputs
oom_score_adj Généralement 0; un nombre inférieur indique que le process sera less susceptible de mourir lorsque le tueur du MOO est invoqué.

Vous pouvez surtout ignorer nr_ptes et swapents bien que je pense que ce sont des facteurs qui déterminent qui est tué. Ce n'est pas nécessairement le process utilisant le plus de memory, mais il est très probable. Pour plus d'informations sur le process de sélection, voir ici . Fondamentalement, le process qui aboutit au score le plus élevé est tué – c'est le "score" rapporté sur la ligne "Mémoire insuffisante"; malheureusement les autres scores ne sont pas rapportés mais ce tableau fournit quelques indices en termes de facteurs.

Encore une fois, cela ne fera probablement pas beaucoup plus que d'éclairer l'évidence: le système a manqué de memory et mysqld été choisi pour mourir parce que le tuer libérerait le plus de ressources . Cela ne signifie pas nécessairement que mysqld fait quelque chose de mal. Vous pouvez regarder la table pour voir si quoi que ce soit d'autre est sorti de la ligne à l'époque, mais il peut ne pas y avoir de coupable: le système peut manquer de memory simplement parce que vous avez mal jugé ou mal configuré les process en cours.

La key de ceci est dans le message lui-même – Mémoire insuffisante . Lorsque le kernel Linux est privé de memory virtuelle (RAM physique plus swap), il commencera à tuer les process et c'est exactement ce qui s'est passé ici. On dirait que mysqld utilisait plus de 2 Go de memory virtuelle.

Combien de RAM et d'échange le système a-t-il? Je envisagerais d'append de la RAM supplémentaire ou, si ce n'est pas possible, d'append un échange supplémentaire. Comme solution rapide pour empêcher au less les process de se terminer, vous pouvez append un file d'échange.

Mise à jour: En regardant la quantité de RAM que vous avez, vous pouvez immédiatement voir le problème. Vous avez ~ 1,6 Go de RAM et 100 Mo de swap, mais MySQL utilise beaucoup plus de RAM que cela. Cela explique pourquoi vous voyez des process être résilié.