SystemTapで真犯人を捕まえろ！：Linuxトラブルシューティング探偵団　番外編（3）（4/4 ページ）

» 2009年03月25日 00時00分公開

コトの顛末——バックポートでめでたしめでたし

　さて、最終的な対処策としてはいくつか方法があります。例えば、以下の3つが候補に挙がるでしょう。

Red Hatにバグを報告し、kernel-2.6.10のパッチをバックポートしてもらう。
HPにccissドライバを修正してもらう。
デーモンを停止し、ストレージの監視をあきらめる。

　3はさすがに問題があるので、1と2のどちらかでしょう。1はそれほど難しいバックポートではありませんし、2に関しても、ccissは本来64bitに対応しているデバイスですので、ドライバ側で対応してもらえれば可能です。

　われわれは両方に対してリクエストを送り、どちらかの対処策が実現されるまでは、危なくなったらリブートするということで顧客に対応してもらいました。そして、最終的に1の提案が通り（https://bugzilla.redhat.com/show_bug.cgi?id=243657）、RHEL 4 Update 6として取り込まれました。現在、この顧客のシステムは当該パッチの入ったカーネルによって運用されています。

各回のまとめ

　3回に分けてお届けした番外編ですが、メモリのトラブルシューティングに際して覚えておいてほしいトピックを各回ごとにまとめてみます。

【第1回で覚えておいてほしいこと】

MemFreeが少なくなることを恐れてはいけない
freeコマンドの結果は物理メモリ使用量の正確な把握には向かない
物理メモリ使用状況把握にはActive、Inactiveを使うべきである

【第2回で覚えておいてほしいこと】

仮想メモリと物理メモリの違い
カーネルにはswapやOOM-Killerなど、物理メモリ枯渇に対する防御機構が存在する
利用可能な物理メモリが極限までなくなるとリブートに至る可能性がある

【第3回で覚えておいてほしいこと】

/proc/meminfoの見方
カーネルの物理メモリ使用量には把握できない部分があること
SystemTapによる解析の有効性

　Linuxのメモリ使用量の把握は本当に、本当に本当に難しい話です。世にある運用監視ツールなどはこの辺りを避けて通っているのか、freeコマンド相当でメモリ使用量を計算している場合も多く、厳密な監視ができていないケースもよくあります。

　メモリ関連でおかしな事象を見つけたら、まずは自分たちが見ている値が、実際には何を把握しているのかを確認してください。そして、メモリ管理の仕組みからおかしな挙動が引き起こされているのかどうかを判断してください。そうすることで、問題解決の筋道がスムーズに構築できます。

おしまいのあいさつ

　今回は、Linuxトラブルシューティング番外編として、カーネルの奥深くまで踏み込む解析を紹介しました。番外編ということもあり、技術的なレベルのリミッターを外してお送りしました。よく読めばなんとか分かる、というレベルを目指したつもりでしたが、いかがだったでしょうか？

　Linuxは現在も進化し続けています。「Linuxはおもちゃだ」といわれる時代から脱却し、エンタープライズ用途にも使われるようになってきました。

　そんな中で実際にトラブルに対応していて感じることは、Linuxの最大のメリットはソースコードが読めるOSであるということです。「何を当たり前な」といわれるかもしれませんが、正直なところ、今回紹介したような例は、ハードウェア、OS、ミドルウェアのすべてがクローズドであったら解決できなかったと思います。

　ソースコードが閲覧できると、切り分けが非常にやりやすくなります。その結果、ベンダ同士の責任の押し付け合いをかなり減らすことができます。記事を最後まで読んでいただいた方には、ぜひオープンソースのメリットを生かしてトラブルに積極的に取り組み、問題解決に結び付けていただければと思います。

　これにてLinuxトラブルシューティング探偵団の活動はひとまず完了となります。しかし、また解決できないような問題が発生した際にはいつでも復活します。また会える日を楽しみにしたいと思います。

　最後に、本解析でともに問題に立ち向かったOSSセンタ前野真輝氏と、事例を公開することを快諾してくださったお客さまに感謝しつつ、連載を締めさせていただきます。長い間ありがとうございました。

「Linuxトラブルシューティング探偵団」バックナンバー