ハングアップするが原因が分からない，性能が出ない――VA Linux Systems Japan 技術本部長 高橋浩和氏らのチームは，こういったLinuxカーネルのトラブルを解決してきた技術者集団だ。その成果はLinuxカーネル2.6にも取り込まれている。どのようにLinuxの内部を解析し，問題を解決するのか。高橋氏に聞いた。（聞き手は高橋 信頼＝IT Pro)
――このところ，数年前に比べ，Linuxがハングアップするといったトラブルの話を聞くことが多くなったように感じます。
 |
| 高橋浩和氏 |
落ちる原因は，カーネルのバグのせいもありますし，Red Hatが提供するパッチが原因で落ちたということもありました。もちろん，アプリケーションの問題であることもあります。
最近調べたケースでは，カーネル内部の情報をプロセスから参照するためのprocファイル・システムにバグがありました。マルチプロセッサ構成のシステムで，プロセスが/proc以下のファイルを参照している時に，別CPU上の処理がまさに参照中のカーネルデータを更新してしまい，OSが停止してしまうというバグでした。
かなり昔ですが，止まるよりも厄介なケースに遭遇したこともあります。稼働中に，メモリーやファイル・システムがじわじわと壊れていくんです。これは，OS内部のデータ構造に矛盾が生じてしまっていたことが原因でした。
ソースコードを追いかけて仮説を立てる
――どのように原因を突き止めるのですか。
どういう場合に落ちたのか，をまず調査します。そしてその状況を再現する。
panicメッセージやOopsメッセージがコンソールに表示されて停止する場合は，原因は比較的簡単に分かります。停止時に実行していた処理が表示され，停止した個所が分かりますから，どのデータが壊れているかを探す。壊れたデータはどこで作られ，更新されたのか，ソースコードをさかのぼって追いかけて仮説を立てていく。次に仮説を基に現象が発生する条件を作り出し，現象を再現させる。
難しいのは，メッセージも表示されず，停止するというケースです。存在しないアドレスにアクセスしようとした場合など，処理が実行できなくなるケースは，OSが検出できますので，panicメッセージやOopsメッセージが表示されます。しかし，カーネル内部で複数の処理が互いに相手の処理が終了するのを待ったままになるデッドロックのような状態や，無限ループのような状態になると，メッセージも表示されずハングアップすることになる。
そのような場合は，停止しているマシンのCPUにマスク不可割り込み（NMI)をかけて，デバッガやメモリー・ダンプのプログラムを呼び出したりします。マスク不可割り込みというのは，CPUチップのピンに信号を与えて強制的にある処理を実行させる仕組みです。ほとんどのサーバーは，NMIを発生させるスイッチを備えているのですが，あるサーバーではスイッチがなく，マザーボードにピンを刺して信号を送ったこともありました。
ネットワークのトラブルを解決したこともあります。通信パケットを記録し，解析して原因を突き止めたのですが，そのケースでは，間にあったファイアウオールの影響で，ホスト同士の通信のネゴシエーションが期待通りには行なわれていなかったことが原因でした。
動きを考え，ボトルネックを探す
――性能が出ない，という場合は。
プロファイリング（どの処理にどれだけ時間が使われたかを集計する機能）はあまり重視していません。処理時間だけを見ても，キャッシュのミスヒットやCPU同士の競合による性能劣化はわかりにくい。
プログラムがどう動いているのか，をソースコードを追いながら考えます。動きを考えながら，最も負荷がかかる，ボトルネックとなっている場所はどこかを探し出す。
カーネル2.6に取り込まれた「ゼロ・コピーNFS」も，カーネルの処理をトレースして新しい処理方式を考え出したものです。従来，NFSはファイルのデータを一度メモリー上にコピーしてから送出していました。ゼロ・コピーNFSでは，コピーする過程をなくすことで，高速化しました。ほかの様々な改良とあわせて，約3倍性能が向上しました。
――Linuxカーネルに正式採用されることは簡単ではありませんよね。
いいプログラムものができたからといって，いきなり送りつけても採用されにくい。我々の場合は，まずバグ修正のパッチを提供することから始めました。何十個とパッチを送付して，こちらの技術力を認めてもらう。
その上で，アイデアの段階からカーネル・メーリング・リストで公表することで，他のカーネル開発者の意見ももらうことができた。多くの開発者の意見をもらうことで，カーネルに取り入れやすくなりました。
現在は，メモリー・ホットプラグ機能を開発中です。稼動中にメモリーを交換する機能です。もちろん対応したハードウエアが必要になるので，メーカーと共同で開発しています。すでにプロトタイプを開発し，カーネル・メーリング・リストで公開しました。米IBMも開発しようとしているようですが，実装したのは今のところ我々だけです。
独自に基本ソフトを開発する機会が減ると，技術力が衰退する
――Linuxカーネルを改良するようになったきっかけは。
Linuxを本格的に手がけたのは，1999年ごろ，あるコンピュータ・メーカー系ISP（インターネット・サービス・プロバイダ）のメール・サーバーを更新するプロジェクトに参加したときです。SoalrisとFreeBSD，Linuxの3種のOSが候補で，それらの検証から始めました。ソースコードを調査してみてLinuxとFreeBSDどちらも十分使用に堪え得るという結論に達しました。周囲にはFreeBSD派が多かったのですが，勢いのあったLinuxを選びました。
ただ，バグ修正や信頼性向上のためにLinuxのソースコードに何カ所か手を入れました。ファイル・システムをマウントする機能にバグを発見し，開発メーリング・リストにパッチを送ったら1時間くらいで返事が返ってきたのを覚えています。また，性能より信頼性を優先するように，ファイルの更新手順を変えたりしました。多数のサーバーによるクラスタ構成をとるメール・システムでしたが，現在も順調に稼働しています。
もともと，コンピュータ・メーカーで独自OSの開発をしていました。電話の交換機やそのほかの専用機に使われるOSです。OSのいろいろな機能を自分で作った。それほど大きなプロジェクトではなかったので，全部自分で見ないといけない。でもOSの仕様を自分決められる。大変でしたが，そのぶん技術を身につけることができました。
しかし，今は独自に基本ソフトを開発する部隊や，その機会はどんどん少なくなっている。このままでは，日本で基本ソフトを開発する力が衰退していくのではないかと危惧しています。
