トラブル発生時にもっとも重要な「問題」は「どこに問題があるか」のを見付ける事だ

「オープンソースマガジン」よろしくお願いいたします！

　先日お伝えしたとおり、月刊誌「UNIX USER」は今月発売号から「オープンソースマガジン」として再スタートを切りました。とりあえず、UNIX USERから比べて若干、というか違いが分かるくらい厚くなっております（ページ数当社比20%増）。にも関わらずお値段そのまま、内容も充実しておりますのでぜひぜひみなさまお買い求めください。ちなみに、定期購読を申し込んでいただくと特別付録としてGoogleの検索コマンドリファレンスがついてきます。

　さて、そういうわけでこのブログの更新も滞りまくっていたわけですが、こちらも本誌リニューアルとともに再スタートということで、オープンソースマガジンの新連載とも絡めて最近のちょっと困った話。

サーバーが不調、どうすれば良い？

　オープンソースマガジンのホームページは、UNIX USER時代からハードウェアとしてヒューレット・パッカード（以下HP）の1Uラックマウントサーバーであるhp rx1620を、OS環境としてHP-UX v11i2を使用して運用しています。

　ちなみに、マシンの構成としては表1の通りで、サーバー本体は編集部ではなく、池袋にある某データセンターに委託して設置してもらっています。そのため、管理はすべてSSHを使用してのリモートログインで行っています。

　ところが、先日このrx1620でトラブルが発生。オープンソースマガジンのホームページでは本誌記事の全文検索サービス（キーワードを入力して検索を行うと、検索した単語が含まれる記事と、そのサマリを一覧表示する）を提供しています。このシステムはオープンソースの全文検索システムである、Estraierをベースに、編集部でカスタマイズを加えたものなんですが、この検索システムのインデックス作成がありえない程遅い。

　インデックス作成作業というのは、対象となる文章ファイルをスキャンして、キーワードとなる単語を抽出してデータベースに蓄える、という作業。ローカルのLinuxマシンでテストをした際は、数分で全文章のインデックスが作成できているのに、rx1620では30分以上経っても終わらない。

　さて、こんな状態の時、管理者は何を考えればよいでしょうか？　考えうる選択肢としては、例えば次のようなものがあるでしょう。

1. (1)インデックス作成が遅いのはマシンが遅いからで、仕方がない
2. (2)とりあえず何かトラブルが起きているみたいだが、システムはまともに動いているので見なかった事にしよう
3. (3)マシンのどこかに不調があるようなので、原因を究明しよう

　ここで(1)(2)を選択した管理者はきっとダメ管理者です。こんな管理者がサーバー管理をしていたら、しばいてやった方がよいでしょう。マシンのスペック的要素では、遅くなる要素はまったくないですし、いまシステムがまともに動いているからといって将来どうなるか分かりません。

　ということで、管理者の自然な反応としては(3)を選択して原因を究明しようとする訳ですが、さて、どうすれば原因が究明できるのでしょうか？　次回に続く。

　ちなみに、このような問題発生時に原因を究明することを、「PD」と呼びます。「PD」とは「Problem Determination：の略で、日本語に直訳すれば「問題判別」というような意味です。今回の作業は「処理が遅い原因をPDする」という感じでしょうか？。

表1　HP RX1620のスペック（抜粋）