PD思考法の基礎と情報収集（その1）（3/3 ページ）

[秋田英行（日本アイ・ビー・エム），ITmedia]

　すると、検証結果は表1のようになり、問題はNFS、BASPドライバの特定バージョン、SMPカーネルの組み合わせにおいて発生することが分かった。よって、この段階で問題の原因となる要素はNFSとBASPドライバに絞り込める。ただし、ログや収集データには兆候が記録されていないため、ハングアップに陥った直接の原因まではまだここでは不明である。

表1　検証構成と再現性

　このような状態でさらに調査を進める場合、メモリダンプ*を取得し、ハングアップ時のNFSとBASPドライバのスタックトレース*を追うことになる。ただし、一般的にメモリダンプの解析はコードデバッグに直結するため容易ではない。

　そこで、解析そのものは開発グループにゆだねたところ、BASPドライバが自身のプリエンプション*のタイミングで発行するBKL*と、NFSが発行するBKLが入れ子状態になったため、デッドロック*に陥っていたことが判明した。BKLのデッドロックが原因でハングアップ状態になっていたのである。結局、この問題はBASPドライバの修正で幕を降ろした。

　以上がPDの流れの一例である。この例では、PDによってNFSとBASPドライバの組み合わせに問題要因があると絞り込めた結果を開発グループと共有した結果、デッドロックを特定できている。このような問題の認識、要因の絞り込み、そして特定といった一連の動きがPDそのものなのである。

PDのポイント

　PDを行うにあたってのアプローチそのものはケースに応じて変わるものの、状況の把握からデータ収集、分析、再現性の確認、特定といった大まかな流れは変わらない。フローチャート的に表現すれば、図3のようになる。

図3　PDの基本的な流れ

●oopsメッセージ
カーネルクラッシュ時に、コンソールに表示されるメッセージ。
●EIPレジスタ
CPUが現在実行している命令がメモリ中のどこに格納されているかを示すレジスタ。

　まず、状況の把握はPDにおける原点である。ここでは、問題の現象を正しくとらえるために事実のみを正確に押さえることが重要である。このフェーズで仮定を持ち出すと、先入観から認識のずれを生じさせ、見当外れなログを取ってしまったり、問題に対する視点がずれたりしてPDを正確に進められない。仮説を立てるのは、ログの分析後になることを忘れてはならない。つまり事実を踏まえログを正しく分析し、問題の状況の特性を見たうえで、再現による調査を行うのが重要なのである。

このページで出てきた専門用語

メモリダンプ

ある時点のメモリの状態をファイルに保存したもの。

スタックトレース

スタックには関数の呼び出し元アドレスや引数などが記録されており、これを調べることで問題の発生した関数がどの関数からどのように呼ばれたかを追跡することができる。

プリエンプション

実行コードの切り替え。実行中のコードを一時中断し、別のコードを実行させること。

BKL

Big Kernel Lock。カーネル全体の動作をロックすること。

デッドロック

複数のプロセスが互いに相手の実行終了を待って動作を停止している状態。お互いに相手が動かなければ自分も動けないため、永久に両者とも停止し続ける。

本記事は、オープンソースマガジン2005年12月号「Linux PD−問題判別脳力養成道場」を再構成したものです。