PDしよう〜システムを観察しろ。PDとはただ見るのではなく注意して"観"て"判断する"ことだ。
PDって何？
さて、PDって聞くと何を思い浮かべるでしょうか？俺は、真っ先にこれを思い浮かべました……。
ご存知ない方のためにご説明しますと、松下電器産業が1995年あたりに発売した書き換え可能な光メディアでPhase-change Dual、略してPD。これ1枚片面で650MBの記録ができます。PDが出た当時はMOとかCD-RWとかZIPとか、書き換え可能な大容量メディアが出回り始めた頃で、「光メディアなのに磁気メディアみたいに自由に書き換えできてすごいじゃん」と感動した覚えがありました。まぁ、当時自分はタダの学生だったためそんなに大容量のメディアなんか必要なかった＆金がなくて買えなかったので雑誌や店頭で見ていただけなんですが。
ということで、今回は前回に続きPDの話。ちなみに、今回出てくるPDはもちろん上のディスクではなくProblem Determination、つまり「問題判別」の話です。
「インデックス作成が遅い」原因を切り分ける
さて、オープンソースマガジンWebサイト運営サーバーで「全文検索のインデックス作成が遅い」という問題が発生しました。そこで、問題の原因がどこにあるのか、PDを行います。
まず、「インデックス作成が遅い」という作業の要素を思い浮かべると、これは以下の要素に分割できます。
- ディスクから検索対象となる文章をメモリ内に読み込む（ファイルからのread）
- メモリ内に読み込んだ文章からキーワードを抜き出す（CPUによる処理））
- キーワードをインデックス化してファイルに書き出す（ファイルへのwrite）
さて、この中でどこが遅いのか、というのを調べて見ます。HP-UXではCPU負荷はtopコマンド、ディスクのアクセス負荷はsarコマンド、またはiostatコマンドで確認できます。以下は、それぞ5秒ごとにCPU負荷、ディスクのアクセス負荷を報告させる例です。
- ○5秒ごとにCPU負荷を表示
- $ top -s 5
- ○5秒ごとにディスクの負荷を表示
- $ sar -d 5 10
- ○5秒ごとにディスクへの転送レートを表示
- $ iostat 5
さて、これらを実行した結果、CPU負荷はほとんどかかっておらず、逆にディスクへの負荷がかなり大きくなっている、ということが分かりました。ここから、問題の原因はディスクにある、ということが推測できます。しかし、rx1620に搭載されている自己診断LEDなどにはとくにエラーの兆候は表示されておらず、ここから先の原因はまったく掴めませんでした。ところが。別件（ssh関連）の設定確認のためにdmesgコマンドを実行したら、以下のようなメッセージが。
LVM: Failed to automatically resync PV 1f021002 error: 5
mpt_TickTock() IO timeout, path = 2, device = 1, resetting bus
SCSI: Read error -- dev: b 31 0x021002, errno: 126, resid: 1024,
blkno: 8, sectno: 1024050, offset: 8192, bcount: 1024.
LVM: VG 64 0x000000: PVLink 31 0x021002 Failed! The PV is not accessible.
LVM: VG 64 0x000000: PVLink 31 0x021002 Recovered.
このメッセージでは、「SCSI: Read error」となっているのでSCSI接続のHDDでエラーが発生していることが分かります。「Recoverd」という文字もあるので、回復されてるのかと一瞬は思うものの、これが連続して何回も表示されているので、何かトラブルが発生していることが分かります。
ということで、結局アクセスが遅い原因はHDDのエラーにあるらしい、ということがわかりました。ただし、これだけでは本当にそこが原因なのか、確信は持てなかったので、HPに連絡を入れ、サポート担当の方の指示どうりにログを取得して送った所、やはりHDDの故障ということとなり、HDDの交換を行ってトラブルは解決。以後インデックスの作成は大幅に高速化されました。
なぜ解決に時間がかかったのか？
さて、結局「全文検索インデックスの作成が遅い」という問題は、「HDDの故障」という原因によって発生していたことが判明し、「HDDの交換」によって無事問題は解決されました。しかし、実は問題が発生してから原因が判明するまで、2週間ほどかかってしまいました。一方で、HPサポート担当者に連絡を入れてから、こちらにログ取得の指示を出し、原因を的確に判断するまで数時間。こちらから「HDDがおかしいようだ」という情報はあったものの、この問題解決に必要な時間の差はどこにあるのでしょうか。
その答えは、問題解決に必要な「情報収集の手段」や、「情報から原因を判断するポイント」についてを知っているか否か、というところにあります。たとえば、私がシステムログ中にSCSIエラーの文字列を発見したのはまったくの偶然です。一方、サポート担当者の方では「問題が発生したらどこを調べればよいのか」という知識、いうなれば問題解決までの最短ルートを知っていた、ということになります。
ちなみに、HP担当者から指示された作業は以下のとおりです。また、HPが公開しているオンラインドキュメント中にも「性能の評価」という項目で問題発生時にPDの手助けになるような情報が公開されています。
- OS情報を表示
- # uname -a
- マシンのモデル番号を表示
- # model
- マシンに接続されているデバイスを表示
- # ioscan -fnk
- カーネルメッセージの表示
- # dmesg
- 接続されているデバイスの情報取得
- # echo 'selal;info;wait;il' | cstm
- LVM構成時のディスク情報取得
- # strings /etc/lvmtab
- LVMのVolume Group構成取得
- # /usr/sbin/vgdisplay -v
- ディスクアクセス（リード）に問題が発生しているかチェック
- # dd if=/dev/rdsk/c2t1d0s2 of=/dev/null bs=2048k
○チェックするログ
- 診断プログラムのエラーログ
- /var/stm/logs/os/log?.raw.cur
- システムログ（syslog）
- /var/adm/syslog/syslog.log
- EMSが記録したイベントログ
- /var/opt/resmon/log/event.log*
問題解決までの最短ルートを学ぼう
ということで、この例はHP-UXサーバーの問題解決の例でしたが、HP-UX固有のものがほとんどであり、Linuxではあまり参考にならないかもしれません。ということで、Linuxをお使いの方はオープンソースマガジン連載の「Linux PD−問題判別"脳"力養成道場」をぜひご覧ください。著者はLinuxにおける問題解決のプロフェッショナルである、秋田英行氏。秋田氏は日本アイ・ビー・エムのLinuxサポートセンターの主任ITスペシャリストであり、豊富な実務経験を元に、Linux環境でのPDの考え方や必要な情報収集、知識などを毎回実例をあげて説明している連載です。