このドキュメントで説明するソフトウェアは、Extended SupportまたはSustaining Supportのいずれかにあります。 詳細は、https://www.oracle.com/us/support/library/enterprise-linux-support-policies-069172.pdfを参照してください。
Oracleでは、このドキュメントに記載されているソフトウェアをできるだけ早くアップグレードすることをお薦めします。
カーネル・クラッシュからのメモリー・ダンプをデバッグするためのステップは、問題に応じて大きく異なります。 次のガイドラインでは、試行できる基本的な調査をいくつか提案します。
btを使用して、カーネル・パニックを発生させた関数をトレースします。
bt -aを使用して、各CPU上のアクティブ・タスクをトレースします。 たいていの場合、あるCPU上のパニックを起こしたタスクと他のCPU上の実行中タスクの間に関連があります。 リストされたコマンドが
cpu_idleまたはswapperの場合、CPU上で実行されていたタスクはありませんでした。bt -lを使用して、スタック・トレースの各関数コールに対応する、ソース・ファイルの行番号を表示します。
kmem -iを使用して、メモリー使用量とスワップ使用量のサマリーを取得します。 500MBを超えている
SLAB値および0%を超えているSWAP USED値を検索します。ps | grep UNを使用して、通常はI/Oの待機中であることが原因の
TASK_UNINTERRUPTIBLE状態(D状態)のプロセスをチェックします。 このようなプロセスはロード平均に関係しており、中断できません。filesを使用して、プロセスでオープンしたファイルを表示します。
次の例のように、間接演算子をシェルで使用して、後で分析するためにコマンドからの出力をファイルに保存するか、grepなどのコマンドを介して出力を送信できます。
crash>foreach files > files.txtcrash>foreach bt | grep bashPID: 3685 TASK: ffff880058714580 CPU: 1 COMMAND: "bash" PID: 11853 TASK: ffff88001c6826c0 CPU: 0 COMMAND: "bash"