サーバーのメモリが完全にいっぱいになり、使用されたため、サーバーが通常のプロセスとチェックの一部に失敗し始めたという問題がありました。
ログの履歴を調べたところ、いくつかの Java プロセスが殺されていることがわかりました。
「top」コマンドを使用して、現在（問題が修正された後）どのプロセスが最も多くのメモリを消費しているかを確認しましたが、それは Java プロセスでした。つまり、現在どのプロセスが最も多くのメモリを占有しているかを知ることができます。
私が知りたいのは、障害が発生し始めたときにどのプロセスが最も多くのメモリを占有していたかを確認する方法があるかどうかです。おそらく、Linux は特定の時間のメモリ使用量を追跡またはログに記録しているでしょうか? よくわかりませんが、そのような詳細を見ることができれば素晴らしいと思います。
@Andy があなたの質問に答えました。ただし、今後の参考のために監視ツールを使用することを追加したいと思います。これらのようなもの。すべてのサーバーを常に監視することは明らかに不可能であるため、これらはクラッシュ中に何が起こったかを示します。それが役に立てば幸い。
カーネルの OOM キラーが作動したということですか? dmesg のログは何と言っていますか? JVM が固定ヒープ サイズを使用するように制限できることに注意してください。つまり、カーネルが他の何かを強制終了するのではなく、いっぱいになったときに肯定的に失敗します。しかし、あなたの質問に対する一般的な答えはノーです。システムのメモリが不足しているため、OOM の失敗時に何かを確実に実行する方法はありません! せいぜい、別のプロセスを使用してプロセステーブルをポーリングし、プロセスサイズをログに記録してメモリリーク状態などをキャッチすることができます...
Linux のメモリ使用量の履歴はデフォルトではありませんが、sar.
メモリに関する問題について: マシン上で何らかの混乱を引き起こしたのが OOM キラーであった場合、(もちろん JVM ヒープ サイズを縮小した後) 再発しないようにするための優れたオプションが 1 つあります。
デフォルトでは、Linux カーネルは実際よりも多くのメモリを割り当てます。これにより、場合によっては、カーネル タスク用のメモリがない場合に、OOM キラーが最もメモリを消費するプロセスを強制終了する可能性があります。この動作は、vm.overcommitsysctl パラメータによって制御されます。
したがって、vm.overcommit = 2issysctl.confに設定してから実行してみてくださいsysctl -p。
これにより、オーバーコミットが禁止され、OOM キラーが厄介なことを行う可能性が非常に低くなります。また、スワップ領域を少し追加して (まだ持っていない場合)、vm.swappiness非常に低い値 (5たとえば、デフォルト値は60) に設定することも考えられます。したがって、通常のワークフローでは、アプリケーションはスワップに入りますが、メモリが非常に不足する場合は、一時的に使用を開始し、df
警告: サーバーがメモリによって過負荷になっている場合、プロセスが「メモリを割り当てられません」というエラーを受け取る可能性があります。この場合：