ダンプ解析パターン集

大きなマシンを借りてベンチマークプログラムを流す。流す。流す。一回あたりの実行時間はものの数分なのであるが、大きなマシンなのでリブートに非常に時間がかかる。大きなマシンなのでというのは、なにが、「〜なので」なのかはわからないが、ともかくそのマシンはそこらへんにあるPCサーバーを物理的に大きくしたような感じのものだから起動時にはBIOSのようなものが走りそれが起動時間のほとんどをしめているというような構成のマシンである。
CPUは16個もついている。CPUのスケーラビリティをはかるため、CPUの数を変化させ同じベンチマークを流す。CPUが1個、2個、4個、8個、16個の時のそれぞれの実行性能を測定する。Linuxカーネル内のボトルネックを発見するために、おなじみのoprofileやらLKSTを仕込んだりして計測している。
http://www.ipa.go.jp/software/open/forum/DevInfraWG.htmlでやったOS層の評価の続きである。
まあ、それはともかく、昼休みにダンプの話になる。Linux Kernel Crash Dump の話である。最近は、kexec/kdumpが本家に取り込まれたというニュースもあり、RHELはnetdumpとかdiskdump、あるいはNTTデータとVAリナックスによるmkdumpさらには日立のLinux Tough Dumpなどリナックスでダンプを取る方式が百花繚乱である。一昔前はリナックスはダンプも取れないのか？とメインフレーマーに散々言われたわけではあるがいまは昔である。ミラクル・リナックスでは昔からLKCD(Linux Kernel Crash Dump)を組み込んでいたが、現場で使われるようになったのはわりと最近の話である。
まあ、それはともかく、リナックスの世界でもカーネルダンプが日常茶飯事、お昼の話題である。
ミッションクリティカルな世界だと、障害が発生した場合、迅速な復旧はもちろん大事だが、それ以上に原因の究明とそれに対する抜本的な対策が求められる。コンピュータ落ちちゃいました。リブートしてください。では許されない世界である。某社のOSの場合、青い画面になって固まるので、現場の人間はリセットボタンを押す。リブートだ。そーゆーことは許されない。
原因を追求するための道具立てのひとつがクラッシュダンプである。障害が発生した時点のOSの精密な情報を取得したものである。それがあるおかげで原因究明の重要な情報源になる。トラブル時のコンピュータのメモリを全て記録したものだから、どこで何が起こったかそれを見ればわかるはづである。実際のダンプは残念ながら必ずしも人間にとって解析しやすいような形で存在するわけではないので、その分析には高度な知識、経験が必要である。
お客さんにとってはいざと言うときのダンプ解析サービスはミッションクリティカルな業務をオープンソースで構築している場合心強い味方になる。某社のOSと違ってソースコードがあるのでベンダーは時間をかければとことん原因追求ができる。（原理的にはね）
メインフレーム時代は各社サポートエンジニアが自社製のOSのダンプを鼻歌交じりに解析していた（らしい）。本当は泣きながら解析していたとしても、わたしは現場に居合わせたわけではないので、実状はわからないが、伝説のプログラマは魔法使いのようにダンプを読んでいたのだろう。
ダンプの問題は、どのようにダンプを取るかという問題から、それをどのように迅速に分析、解析し、障害原因の追求に役立てるかというフェーズに来つつある。ダンプ解析は、それ自身が高度な専門性を必要とするから、それなりのお値段を請求できるサービスになるのだがいかんせん専門家が少なすぎる。
そこで、サポートの専門家を集めてダンプに関するワークショップをやろうではないかという企画を練っている。昔はOSが非公開だったのでダンプ解析のノウハウは各ベンダーに閉じていて、外に出ていくということがなかった。各社のサポートエンジニアも職人肌の人が多くて積極的にダンプの解析手法を同僚後輩に伝授するという人も少なかったと聞く。ダンプ解析に王道はない、「ソースを読め」というスタイルである。
オープンソースの場合、OSが共通なので、ノウハウの交換は原理的には可能である。職人肌のエンジニアが喜んで自分のノウハウを提供するというインセンティブが見えにくいだけである。ナイーブな言い方をすると自分の飯の種をなぜただで教えなくちゃいけないのか、まして同業他社へ、という考え方である。
ダンプ職人10年選手の経験と知恵をオープン化して業界で共有できればオープンソースの価値は商用OSのそれと比べて飛躍的に高まることになる。まちがいない。知識を囲い込まない。それが業界にとっても各社にとっても利益になる。この考え方が多くの企業、会社員、ダンプ職人に共有されれば進歩は加速する。
「これはノウハウだからだせないなあ」と言う企業の方がいっぱいいることをわたしは知っている。だけどソースコードが開放されている状況で、たまたま先に知ったという知識を秘蔵することによる優位性というのがどれほどあるのか？はなはだ疑問である。
ダンプの解析なんかは言ってみればポインターをひたすら追っていくこと。データ構造の意味を理解して、どのタイミングでどのフィールドの値が変化するかを理解すること、…というようなことにつきる。頭の中に整理しておいておく知識量が大規模ソフトウェアの場合、規模的に大きいが、それも各種ツールを利用すれば、知識の差だけでは、競争優位性の源泉にはなりえない。
解析手法そのものがノウハウになるのであるがそれも誰かがオープンにすればあっと言う間に定跡化するであろう。あなたが秘匿していたとしてもわたしがそれを公開する。という時代であり、秘匿することにメリットはほとんどない。
ダンプ解析のベストプラクティスを集めて分類してパターン化して名前を付ける。デザインパターンみたいなものを作る。クラッシュした時の解析手法。ハングした時の解析手法…、そーゆーダンプパターン集を作ろうとかいう話で盛り上がった今日このごろである。