解決策 1:
oom のログ ダンプを見たところ、そのグラフの正確性に疑問があります。最初の「Node 0 DMA32」行に注目してください。 free:3376kB と表示されます 、 min:3448kB 、および low:4308kB . free の値が低い値を下回ると、kswapd はその値が高い値を上回るまでスワップを開始することになっています。フリーが最小値を下回ると、カーネルが最小値を上回るまでシステムは基本的にフリーズします。このメッセージは、Free swap = 0kB と表示されている場所でスワップが完全に使用されたことも示しています。 .
つまり、基本的に kswapd がトリガーされましたが、スワップがいっぱいだったので何もできず、pages_free の値はまだ pages_min の値を下回っていたので、pages_free が元に戻るまでキルを開始するしかありませんでした。
間違いなくメモリ不足です。
http://web.archive.org/web/20080419012851/http://people.redhat.com/dduval/kernel/min_free_kbytes.html には、それがどのように機能するかについての非常に良い説明があります。下部の「実装」セクションを参照してください。
解決策 2:
drop_caches スクリプトを削除します。さらに、 dmesg の関連部分を投稿する必要があります および /var/log/messages OOM メッセージを示す出力。
ただし、この動作を停止するには、この sysctl を試すことをお勧めします 調整可能。これは RHEL/CentOS 6 システムであり、明らかに限られたリソースで実行されています。仮想マシンですか?
/proc/sys/vm/nr_hugepages を変更してみてください 問題が解決しないかどうかを確認します。これはメモリの断片化の問題である可能性がありますが、この設定が違いを生むかどうかを確認してください。変更を永続的にするには、vm.nr_hugepages = value を追加します あなたの /etc/sysctl.conf に sysctl -p を実行します 構成ファイルを再読み込みするには...
参照:不可解なカーネル「ページ割り当て失敗」メッセージの解釈
解決策 3:
OOM キラーが開始してから終了するまで、グラフで使用できるデータはありません。グラフが中断される時間枠は、実際にはメモリ消費が急増し、使用可能なメモリがなくなると信じています。そうしないと、OOM キラーは使用されません。 OOM killer が停止した後に空きメモリのグラフを見ると、以前よりも高い値から下がっていることがわかります。少なくとも、適切に機能し、メモリを解放しました.
スワップ領域は、再起動するまでほぼ完全に使用されることに注意してください。これは決して良いことではなく、空きメモリがほとんど残っていないことを示しています。
その特定の時間枠で利用できるデータがない理由は、システムが他のことで忙しすぎるためです。プロセス リストの「おかしな」値は、原因ではなく単なる結果である可能性があります。前代未聞ではありません。
/var/log/kern.log と /var/log/messages を確認してください。そこにはどのような情報がありますか?
ロギングも停止した場合は、他のことを試してください。システム パフォーマンス情報と同じように、1 秒ごとにプロセス リストをファイルにダンプします。高い優先順位で実行して、負荷が急増した場合でも (できれば) ジョブを実行できるようにします。ただし、プリエンプション カーネル (「サーバー」カーネルと呼ばれることもあります) を持っていない場合は、その点でうまくいかない可能性があります。
問題が発生する頃に最も多くの CPU% を使用しているプロセスが原因であることがわかると思います。 rsyslogd も mysql もそのように動作するのを見たことがありません。原因の可能性が高いのは、Java アプリや、ブラウザーなどの GUI 駆動型アプリです。