kdump / crashを使用してOOMの問題を調査する方法は?
問題 複数の「メモリ不足」メッセージの後にサーバーがクラッシュし、原因を特定しようとしています。ユーザーランドにある場合-どのプロセス。カーネル内にある場合-どのカーネルモジュール。 詳細 クラッシュユーティリティを使用して、サーバーでOOMをトリガーした原因を調査する方法を見つけようとしています。 新しいサーバーペアのインストールの一環として、14TB DRBDデバイスの初期化を開始しました。その頃、DRBDシンカーレート構成で遊んでいるときに、結合されたネットワークインターフェイスの一部を上下させたときに、サーバーの1つがクラッシュしました。30秒間で39のOut of memory: Kill process ####メッセージが生成されました。その後、次のようにクラッシュしました: Kernel panic - not syncing: Out of memory and no killable processes... システムクラッシュによりkdumpがトリガーされました。これでvmcore.flat、問題を調査するのに簡単に使用できる素敵なファイルができましたが、すべてのメモリがどこに行ったのかを見つけるのに苦労しています。 私が知っている唯一のリソースはDedoimedoのサイトで、これには素晴らしい説明があり、Kernel Crash Bookがあります。これらは回答で提案されている唯一のリソースでもあるためcrash、調査する唯一の方法であると思います。 インシデントで事後分析を行う別の方法があれば、喜んで受け入れます。それはcrash私が知っている唯一のユーティリティです。私が今持っているのはvmcore.flatファイルだけです、そして、私が知る必要があるのは、どのコンポーネントがそのメモリをすべて使い果たしたかです。カーネルモジュールの問題、より具体的にはボンディングモジュール(インターフェイスをダウンさせるとトリガーされる)、DRBDモジュール(CentOS 6.3のツリーからビルドされたバージョン8.3.15)、または10Gイーサネットモジュール(mlnx_en停止したインターフェイスであるツリー、またはbnx2xアクティブのままであったインターフェイスであるツリーから構築されます)。私が知る必要があるのは、疑念を検証する方法があるかどうかだけです。 これまでのところ、クラッシュユーティリティを使用して次の情報を抽出することができました。 使用メモリ量を確認しました $ crash /usr/lib/debug/lib/modules/2.6.32-279.5.2.el6.x86_64/vmlinux vmcore.flat .... crash> kmem -i PAGES TOTAL PERCENTAGE TOTAL MEM 16482587 62.9 GB ---- FREE 54610 …