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

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

PDとは

　PDとはProblem Determinationの略である。直訳すれば、「問題を確定する」などになるだろう。われわれは問題の切り分けをし、問題部分を特定する、つまり問題判別することをPDと呼んでおり、「PDをする」「PDはどこまで進んでいる」といった使い方をする。

　PDを行う目的は、問題要素を特定することにある。それに対し、要素内のプログラムの問題個所を特定しステップ修正するという作業、debug＆fixは開発の役割であり、PDではない。場合によってはPDでデバッグまで踏み込む必要性も生じるが、それは基本的にはPDの役割ではない。コードのバグを発見し修正するには、バグを持つコードを含む要素を特定する必要がある。その要素に到達するまでの道のりを明確にし、問題の発生源を特定するのがPDである。

PDの例

　それでは、ある問題を例に、PDの流れを説明してみよう。

問題：突然システムが無反応になってリブートしなければ機能しない

　さて、このような連絡が入ったとき、あなたならどう対応するであろうか？　なお、これは実際にあったケースである。

　まず、システムが使えない状態になっていることは把握できる。しかし、これだけでは何が起きているのかまでは当然把握できない。そこでまず、無反応とはどういう状態なのか、カーネルがハングアップしているのか、それともカーネルパニックを起こしているのか、はたまた過剰負荷による一時的な問題なのかなど、発生した事象に対する正確な情報を収集することが必要である。発生した事象によって、あとの具体的な対応も変わってくるからだ。

　状況の詳細を調べると、ネットワークアクセスは不可、コンソールにはパニックメッセージは表示されていない。収集したデータを見ると、残っている記録からはCPU使用率が30％を切っている状態が続いていたことが分かった。以上の情報から、過剰負荷でもなくパニックでもなく、システムがハングアップしている状況だということが分かる。

　システム構成としてはNICのチーミング*を行ってNFSクライアントを構成し、ユーザープロセスがNFSアクセスを行うというものであった。また、チーミングにはBASPドライバ*を使用している。さらに、ユーザープロセスを走らせて通常のオペレーションを続けるとハングアップするということが分かった。以上の状況をまとめると、図2のようになる。

図2　問題の発生例

　さて、これでNFS、チーミング、NIC（ファームウェアおよびドライバ）、カーネルといった、疑うべき要素は揃った。しかし、それぞれの設定情報、ログ、過去のバグリポートなどを調査しても、発生した現象に合致するような問題の痕跡はどこにもない。また、再現環境によってその挙動を確認することはできていたが、何が原因なのかは特定できない。

　そこで、構成を変えたいくつかの環境を用意し、それぞれの挙動を比較することで問題の絞り込みを行う。問題発生個所としてNFS、NIC、カーネルにフォーカスし、それぞれの構成を変えて再現性を確認するのである。

　今回のケースでは、NFSとネットワークに対してI/Oを発生させるのが基本となる。NFSに対するI/Oの発生には、以下のようにddコマンドを使用する。

# dd if=/dev/zero of=<NFS上のファイル名> bs=32k count=10000

　ネットワークI/Oの発生にはFTPを使用する。

# ftp 　：（FTPサーバーにログインする） ftp> put "| dd if=/dev/zero bs=32k count=10000" <ファイル名>

　双方ともサイズは状況に応じて変えていただいてかまわない。ただし、適度な負荷は必要である。上記の例では、320Mバイトの書き込み転送が行える。

　また、構成としては以下の疑わしい要素をそれぞれ組み合わせて検証を行った。

• I/Oの発生源（NFSまたはFTP）
• チーミングのあり/なし
• BASPドライバのバージョン
• カーネル構成

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

NICのチーミング

複数のNICを束ねて仮想的に1つのNICとして使用することにより、冗長化や通信速度の向上、負荷の分散を図ること。Bondingとも呼ばれる。

BASPドライバ

Broadcom Advanced Server Programドライバ。BroadcomチップセットのNICドライバ（bcm5700）にバインドされてチーミングを構成するドライバ。