/var/log/messages でメモリ不足をデバッグする

/var/log/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

この問題が の場合でも の場合でも問題ありませんがhttpd、どうすれば問題のデバッグを続行できるか知りたいです。mysqldpostfix

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 つの場所にしか表示されないはずです。それが確認したいファイルです。

も含まれているファイルの 1 つで、元の「メモリ不足」行を見つけます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

すでに知っていること以上のことはわからないかもしれませんが、フィールドは次のとおりです。

  • ピッドプロセス ID。
  • ユーザIDユーザーID。
  • tgidスレッド グループ ID。
  • 合計VM仮想メモリ使用量(4 KB ページ単位)
  • rss常駐メモリ使用量(4kB ページ単位)
  • 翻訳者ページテーブルエントリ
  • スワペントエントリの交換
  • oom_score_adj通常は 0 です。数値が低いほど、OOM キラーが呼び出されたときにプロセスが終了する可能性が低くなります。

ほとんど無視できますnr_ptesが、swapentsこれらは誰が殺されるかを決定する要因であると私は信じています。これは必ずしも最も多くのメモリを使用するプロセスではありませんが、そうである可能性は非常に高いです。選択プロセスの詳細については、こちらをご覧ください基本的に、最も高い oom スコアを獲得したプロセスが強制終了されます。これが、「Out of memory」行に報告される「スコア」です。残念ながら他のスコアは報告されませんが、この表は要因に関していくつかの手がかりを提供します。

繰り返しますが、これはおそらく明白な事実を明らかにする以上のことはしないでしょう。システムはメモリ不足になり、mysqld死ぬことを選択したのです。殺すと最も多くの資源が解放されるからだこれは、必ずしもmysqld何かが間違っていることを意味するわけではありません。表を見て、その時点で何かが間違っていたかどうかを確認できますが、明らかな原因がない可能性があります。実行中のプロセスを誤って判断したり、誤って構成したりしただけで、システムがメモリ不足になる可能性があります。

答え2

その鍵はメッセージそのものにあります -メモリ不足Linux カーネルの仮想メモリ (物理 RAM とスワップ) が不足すると、プロセスの強制終了が開始されますが、ここでもまさにそれが発生しています。2 mysqldGB を超える仮想メモリを使用しているようです。

システムの RAM とスワップの容量はどれくらいですか? RAM を追加するか、それが不可能な場合はスワップを追加することを検討します。少なくともプロセスが終了しないようにするための簡単な修正方法として、スワップ ファイルを追加できます。

アップデート:搭載されている RAM の量を見れば、すぐに問題がわかります。搭載されている RAM は 1.6 GB 程度で、スワップは 100 MB ですが、MySQL はそれよりもはるかに多くの RAM を使用しています。これが、プロセスが終了している理由です。

関連情報