どうも最近、mt.cgiでの更新時、500エラーで止まることが多い。かと言って確実にエラーが出るわけでも無い。Perl CGIの動作が不安定というところだろうか。根本的に調査しないとダメっぽい。
先に結論
うちのMovable TypeはDELLのT105というAMD社のOpteron クアッドコアサーバ上で動いている、VMWare社のESXiという仮想サーバ上のCentOSのWebサーバで稼動している。最終的にはこのESXi仮想サーバーに問題があったらしく、全てのゲストOSを停止してから、ESXiを再起動したら全てクリアーとなった。
以下に顛末を記しておく。将来の自分のためにね。
休日、ようやくSSHでログインしてみて、topコマンドを叩いて見た。
・・・・なんだこりゃ？
topで表示されるプロセスリストがチラチラして何かがリソースを食いまくっているであろうことが容易に想像できる。しかしチラチラしすぎてプロセス名が読み取れない。何が原因なんだこれ？
topのプロセス監視更新時間を長くしてみた。普通は秒単位らしいが下記のようにしないとほとんどチラチラが落ち着かず何がリソースを食っているのか読めなかった。
$ top -d 100やっとこさ捕まえたプロセスは「hald-addon-stor」と表示されたので、こいつをGoogleで検索した。すると正式なプロセス名は、「haldaemon」だと分かった。storってのが気になるがなんとなくstorage（ストレージ）の様な気がする。HDD異常？
cat /var/log/messages | grep kernel >
/home/sasapurin/20100311error.txtCode language: JavaScript (javascript)ログからカーネル系のエラーを抽出してみる。これでじっくり分析できる。と思って調べてみたが全然原因らしきものが見つからない。ログに残らない原因って何だ？
ふと思った、このWebサーバーは、VMWare ESXiサーバ上で動いている。もしかしたらESXi（言い換えれば仮想化ホストサーバ）の不具合でおきているのではないか？OS上のプロセスも問題ない
しもうそれしか考えられない。ESXiの状態を確認してみて驚愕した・・普段は大人しいWebサーバがCPUリソースを食いまくっている・・・やっぱり異常だったんだ。
もうこうなったら、ホストの問題であってくれと願うばかり。仕方ないので全てのゲストOSをシャットダウンして、敢えてメンテナンスモードではなく通常モードでVMWare ESXiサーバを再起動した。
まず、仮想サーバー上で動かしているWindowsサーバが上がってきた。これは自動起動設定しているので正常な状態だ。このWindowsサーバのAD（つまりDNS）を使ってLAN内部の名前解決をしているので一番最初に上がって欲しいのだ。次に遅延をかけている今回の問題となっているWebサーバが起動してきた。起動中はCPUリソースは大人しいぞ。この調子で上がってくれ・・
最終的に確認したら、症状はピタっと納まった。CentOSは普段どおりのリソース消費に納まり、SSHから入ってtopコマンドを入れてみてもチラチラ暴走の気配は無くなった。今回気づいたMovableTypeよりエントリーを投稿してみる。500エラーは出なくなった。良かったー、要するに500エラーの原因は、Webサーバ（CentOS）がホストの異常により不安定な状態に陥りリソース食いまくりの暴走モードと鳴っていたという事だ。何もプログラムの追加や変更をしていないのに急にMTが500エラーを出す様になったので今回はある程度原因を絞りやすかった。
ただ、理論的に追いかけていかないと分かりづらかったのは、仮想サーバーにしているため、CPUリソースを食いまくっても、割り当てている上限で止まってしまい、仮想サーバー全体には影響を及ぼさなかったことだ。リアルサーバーの場合は処理能力が致命的に低下したりするので、気づきやすいが、今回はOpteronのクアッドサーバーだったので、ハードウェア的にはまだ余裕があった為、他のゲストOSには影響がほとんど無かった。逆に言えば仮想化しているおかげでお隣さんに被害を与えなかったとも言えるが、結局はVMWare ESXiサーバの再起動を余儀なくされたので、被害は全部に及んだとも言える。
まだまだESXiサーバとの付き合いは浅いし、職場にも導入してしまったので癖やトラブル時の対応を自宅ででも有る程度把握しておかねばと思う次第である。とりあえず実害は殆ど無かったので良しとしよう。まだまだESXiサーバも改善の余地アリってところだろうか？VMWare社には頑張って原因を調べてもらって改善パッチをリリースしていただきたく願う。
コメント