マイメッセージログに次のレポートが表示されます。
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
httpd
この質問がターゲットであるかどうかは問題ではありませんが、mysqld
問題postfix
を引き続きデバッグする方法がわかります。
PID 9163が終了した理由に関する追加情報をどのように取得できますか? Linuxが終了したPID履歴をどこかに保持しているかどうかはわかりません。
メッセージログファイルでこの問題が発生した場合は、この問題を段階的にどのように解決しますか?
# free -m
total used free shared buffers cached
Mem: 1655 934 721 0 10 52
-/+ buffers/cache: 871 784
Swap: 109 6 103`
答え1
これが発生する前に、カーネルは多くの内容を記録しますが、設定/var/log/messages
方法によってはほとんどログインできない場合があります(r)syslogd
。努力する:
grep oom /var/log/*
grep total_vm /var/log/*
前者は何度も現れなければならず、後者は1、2箇所にしか現れないでください。見たいファイルです。
total_vm
その行の前に30秒から1分(おそらくもっと多いかもしれません)、以下の内容が表示されます。
kernel: foobar invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
また、この行と「メモリ不足」行の間には、次のタイトルのテーブルが必要です。
[ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name
これはおそらくあなたがすでに知っている以上のことを知らせないでしょう。ただし、これらのフィールドは次のとおりです。
- PIDプロセスID。
- UIDユーザーID。
- tgidスレッドグループID。
- 仮想マシンの総数仮想メモリ使用量(4kBページ)
- RSS常駐メモリ使用量(4kBページ単位)
- nr_ptesページテーブルエントリ
- 通貨交換交換アイテム
- oom_score_adj通常、ゼロが低いほど、OOM Killerが呼び出されたときにプロセスが終了する可能性が低いことを意味します。
基本的に無視しても構いませんがnr_ptes
、swapents
私はこれが誰が死ぬかを決める要素だと信じています。これは必ずしも最も多くのメモリを使用するプロセスではありませんが、おそらくそうです。選定プロセスの詳細は、ねえ。デフォルトでは、最高のoomスコアで終わるプロセスは終了します。これは、「メモリ不足」行に報告された「スコア」です。残念ながら、他のスコアは報告されていませんが、表は要因に関するいくつかの手がかりを提供します。 。
もしそうなら、もう一度、これは明らかな事実を説明することができます。システムにメモリが不足してmysqld
シャットダウンを選択しました。殺すと、ほとんどのリソースが確保されるからです。。これが必ずしもmysqld
何かが間違っているという意味ではありません。テーブルを見れば、当時他の問題があるかどうかを確認できますが、明確な原因はないかもしれません。実行中のプロセスを誤って判断したか、誤って設定したため、システムにメモリが不足している可能性があります。
答え2
鍵はメッセージ自体にあります。十分な保存。 Linux カーネルに仮想メモリ (物理 RAM + スワップ) が不足するとプロセスが終了し始めますが、これがここで起こっていることです。mysqld
仮想メモリが2GB以上使用されているようです。
システムにどのくらいのRAMとスワップスペースがありますか?追加のメモリを追加することを検討するか、可能でない場合は追加のスワップ領域を検討してください。少なくともプロセスが終了するのを防ぐために、迅速な修正でスワップファイルを追加できます。
修正する:あなたが持っているRAMの量を見ると、すぐに問題を確認できます。約1.6GBのRAMと100MBのスワップスペースがありますが、MySQLはそれよりはるかに多くのRAMを使用します。これは、プロセスが終了する理由を説明します。