2010年03月12日
Movable Typeが500エラーで止まる
どうも最近、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.txt
ログからカーネル系のエラーを抽出してみる。これでじっくり分析できる。と思って調べてみたが全然原因らしきものが見つからない。ログに残らない原因って何だ?
ふと思った、この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社には頑張って原因を調べてもらって改善パッチをリリースしていただきたく願う。
投稿者 sasapurin : 10:30
| コメント (0)
| CentOS
, Movable Type
, Webアプリ
, コンピュータ
| トラックバック
|
2009年07月01日
CentOSでFFFTPから削除できない
Karesansuiを使ってXen仮想環境を快適に使っている。一つベースとなる環境を作っておけば、それをコピーして新しい環境として利用できるので、クローンの生成は非常に効率的である。
しかし、ベースとする環境の設定が不十分だと、クローン環境にもそのまま継承されてしまい思わぬトラブルに悩まされることになる。今日は下記のようなことになった。
クローンした仮想環境でWindowsのFFFTPから不要ファイルを削除しようとしたら、削除できなくて困ったといいう相談を受けた。確認してみたがパーミッションの問題でもないし、ユーザーアカウント=オーナー番号も同じなので削除できないのは変だなぁと首をかしげた。
もちろんSSHで入り込んでbashを使えばコマンドラインから削除は出来る。何があかんのかなぁ?とFFFTPで操作しているのを見せてもらい、空のフォルダを削除できないという状況を確認した。そして思った・・本当に空なのかな?
bashシェルからsuでそのユーザーアカウントになり、当該フォルダをls -laで見たところ、ドットファイルがあった。やっぱり空では無かった!!
#ドットファイルとは、.htaccess という感じに"."から始まるファイル名。UNIX系OSでは隠しファイルになるので、lsコマンドでは見えずaオプションをつけないと見えない。FFFTPの挙動はUNIXコマンドとは違うと分かっていたので、おそらく再帰的にフォルダ階層を掘り下げてリスティングし、ファイルを一個ずつ削除しているものと思われる。
故に、ドットファイルが見えないからFFFTPは削除しておらず、空でないフォルダは削除できないという図式だろう。bashシェルからドットファイルを削除してからFFFTPで実験したら問題なくフォルダを削除できた。
解決方法は色々あるだろうが、手っ取り早く思いつくのは下記の方法だ
- WindowsなどからFTPコマンドでアクセスして、FTPコマンドで削除する方法。
- FTPサーバの設定を変更してドットファイルを可視状態にしてFFFTPでも削除できるようにする方法。
CentOS5.3環境で作っているテスト環境は、FTPサーバとしてvsftpdをインストールしてある。vsftpdでドットファイルを可視状態にするには、下記のようにvsftpd.confを編集して再起動すれば良い。FFFTPでも見られるようになり、削除も出来るようになった。
#vi /etc/vsftpd/vsftpd.conf
force_dot_files=YES
# Service vsftpd restart
これは必須な設定だと思えるので、CentOSセットアップ手順書というか備忘録に記しておくことにした。
投稿者 sasapurin : 13:09
| コメント (0)
| CentOS
, UNIX系
, オープンソース系
| トラックバック
|
2009年06月30日
YAMAHA RTX1100をCentOSのシリアルポートから
YAMAHA RTX1100を最初に設定するには、シリアルポートから行わないとどうしようもない。
ところが最近はシリアルポートが無いPCが多くなった・・・
ふとLinux Serverを見るとシリアルポートがあるではないか。
どうせここに設置するんだし、常時接続しておけばSSH経由で
WindowsPC->Linuxサーバ->シリアルポート->RTX1100
という風にリモートできるわけですな。
しかし実際にやってみると苦労もあった。もう二度と同じ苦労はしたくないので備忘録しておく。
下記のようにした
- シリアルケーブルでLinuxサーバとRTX1100接続
- WindowsPCからSSH(PuTTYとか)でLinuxサーバに接続(文字コードはSJIS)
- Linuxサーバのscreenコマンドで接続する
# screen /dev/ttyS0 9600 -> 文字化けするのでSJIS化する - エディタでscreenの設定ファイルを編集する
# vi /etc/screenrc
encoding sjis
defencoding sjis - 再びscreenコマンドで接続する
# screen /dev/ttyS0 9600 - 空ENTERを押したらRTX1100がパスワードを聞いてくる。
- 後はおのれとYAMAHAルーターコマンドの格闘
投稿者 sasapurin : 20:11
| コメント (0)
| CentOS
, Network系
, ハードウェア
| トラックバック
|
2009年06月26日
CentOSにPostgreSQL 8.2系をインストール
普段はMySQLしか使ってないので、PostgreSQLのことは良く分からないのだが、職場の同僚がどうしても8.2系か8.3系を使いたいって言うので、8.2系をインストールすることにした。
インストールするにしても、yumの管理が楽なのでこれは守りたいところ。リポジトリ無いのかな?と思って調べてみたら有った。ありがたいことだ。(今後メンテされるかどうかは分からないが)
http://yum.pgsqlrpms.org/reporpms/8.2/
# rpm -ivh http://yum.pgsqlrpms.org/reporpms/8.2/pgdg-centos-.2-4.noarch.rpm
# yum search postgresql
# yum info postgresql.i386
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: ftp.nara.wide.ad.jp
* updates: ftp.nara.wide.ad.jp
* addons: ftp.nara.wide.ad.jp
* extras: ftp.nara.wide.ad.jp
Available Packages
Name : postgresql
Arch : i386
Version : 8.2.13
Release : 1PGDG.rhel5
Size : 1.6 M
Repo : pgdg82
Summary : PostgreSQL client programs and libraries
URL : http://www.postgresql.org/
License : BSD
Description: PostgreSQL is an advanced Object-Relational database management
: system (DBMS) that supports almost all SQL constructs (including
: transactions, subselects and user-defined types and functions). The
: postgresql package includes the client programs and libraries that
: you'll need to access a PostgreSQL DBMS server. These PostgreSQL
: client programs are programs that directly manipulate the internal
: structure of PostgreSQL databases on a PostgreSQL server. These
: client programs can be located on the same machine with the
: PostgreSQL server, or may be on a remote machine which accesses a
: PostgreSQL server over a network connection. This package contains
: the command-line utilities for managing PostgreSQL databases on a
: PostgreSQL server. If you want to manipulate a PostgreSQL database
: on a local or remote PostgreSQL server, you need this package. You
: also need to install this package if you're installing the
: postgresql-server package.
投稿者 sasapurin : 11:00
| コメント (0)
| CentOS
| トラックバック
|
2009年06月12日
Karesansui 1.0.1 64bit and AMD Support
先日、お試ししていい感じになったXenハイパーバイザをWebサービス上で管理できる「Karesansui」が早速バージョンアップして、Ver 1.0.1になった。
バージョンアップ内容の目玉としては、
- AMDプロセッサ対応
- 64bit OSサポート
と、待ち望んでいた条件が整ったので早速片手間ながら32bit環境を捨てて64bitで作り直した。幸いゲストOSはテストに使ったけれど要らなくなったので削除してしまっても問題ない。一ヵ月後とかに出されたらぶーぶー文句言ってただろうが、このタイミングに64bit対応はまだ環境再構築に間に合うからうれしい。
CentOS 5.3 x86_64を再インストール。もちろんXenハイパーバイザをシンプルにインストールだ。
アッサリインストールが終わり、Wheelユーザを作ってからはSSHで作業する。自分のデスクにあるWindowsXPパソコンからPuTTYを使ってSSHだ。LAN内部の使用で外部には公開していないので暗号化Key等は考慮していない。
PuTTYからのインストールだと、テキストインストール画面の体裁が崩れる。これは前回インストーラを修正してやった時と同じだから改善されていない。
Karesansuiの導入もスコッと終わり、ゲストOSをインストールしてみる。CentOS 5.3 X86(32bit)をインストールした。GUIは全くなしで極々シンプルにね。これは私のいつもの手法。FeeeBSDで慣れた手法なので最小構成からインストールしていく。
一連の手順は社内のWikiに記しておいたので何の問題も無く32bit環境から64bit環境に変更出来た。まぁゲストOSをため込んでいたらこうは行かないけどね。早い内に64bit対応させて下さった開発陣にお礼を言いたいものだ。
完全仮想化までサポートしてくれたらXen対応カーネルが付いていないVineなんかでもテスト出来るんだけどね。これからのディストリビューションはXen対応のカーネルを添付して欲しい、もしくはDLできる様にして欲しいものだ。
一度通った道なので苦労もなくすんなり出来た。後は最小構成インストールのksファイル(キックスタート)を共有出来るようにしてスコッと手抜きインストール出来るようにしたいものだな。
投稿者 sasapurin : 16:42
| コメント (0)
| CentOS
, Linux
, UNIX系
, Webアプリ
, オープンソース系
, コンピュータ
| トラックバック
|
2009年05月30日
Karesansui Project
職場のOpteronサーバでXen環境を構築する計画で時間が無くて保留していたんだが、 「Karesansui Project」のリリースをきっかけに行動を起こしてみた。
早い話、XenハイパーバイザをGUIで(ブラウザ経由で)管理できるというOSSプロジェクトである。CentOS 5.3が対応となっている。
チュートリアルの図が下記のようになっていて、HostOSはCentOS5.3-32Bitと書いてあるのが気になりつつも、手元に64bitのDVDしか用意してないのでチャレンジしてみた。
見事に玉砕した・・・
karesansui-1.0.0-1-install-pack.tar.gz をダウンロード後解凍し、
karesansui-install を実行したところ下記のメッセージが帰ってきた・・・
ERROR: Processor 'x86_64' is not supported by Karesansui.
オーマイガッ
どうせなら64bitで構築したいから、karesansuiが64bitに対応するのを待つしかないかな。
それとも32bitで検証するか・・・やっぱり初物に飛びつくのは人柱覚悟でって事か。
推奨スペックがいまいち分かりにくい。
CPU : Intel Core 2 Duo以上
Opteron 2.2GHzはもちろんデュアルコアなのだが、 Intel Core 2 Duo以上なのか否か?
リリースされたばかりのプロジェクトだけに、まだ情報が洗練されてないよな・・
ERROR: Processor 'athlon' is not supported by Karesansui.
オーマイガッ!!!
またかよっ。Intel CPUしかサポートしてないとは書いてないで・・ちゃんと明記してくれよな。要するに現状は下記要件をクリアしないとすんなりとインストールすることは出来ないらしい
- CentOS 5.3 32bit (64bitは未サポート)
- Intel Core2 Duo マシン (AMDは未サポート)
- メモリー 2GB以上
- HDD 100GB以上
無駄な時間を使ってしまった。もういい、CitrixのXenServerでいく事に決めた。
と思っていた矢先、MLにてAMDプロセッサへの対応についての投稿があり、Karesansuiとしては制限をかけてはいないので、インストーラ(スクリプト)のバグだろうというコメントがついた。そして2つのファイルを編集すればOpteronサーバでもインストーラが走った。
ML以外にはまだ情報が無いようなので備忘録を兼ねて引用しておく。
(MLのアーカイブが公開されていたのでスレッドトップにリンクしとく)
近いうちにバグ修正されるだろうが。修正するファイル(インストーラ)は下記の2つ
installer/installer/const.pyに下記の部分を探して+のついている行を追記
@@ -38,6 +38,10 @@ SUPPORTED_DISTROS = [
("centos", "5-3"),
("redhat", "5Server-5.3"),
]
+SUPPORTED_ARCHS = [
+ "^(i[3456]86)$",
+ #"^(x86_64)$",
+]
installer/installer/install.pyに下記の部分を探して+のついている行を追記-のついている行を削除
@@ -140,13 +140,15 @@ def precheck(opts):
# architecture check (now supported arch is x86 only)
if ret is True:
import platform
- arch = platform.processor()
- x86_regex = re.compile("^(i[3456]86|athlon)$")
- if x86_regex.search(arch):
- pass
- else:
- print >>sys.stderr, _("ERROR: Processor '%s' is not supported by Karesansui.") % arch
- ret = False
+ arch = platform.machine()
+ for support_arch in SUPPORTED_ARCHS:
+ _regex = re.compile(support_arch)
+ if _regex.search(arch):
+ ret = True
+ break
+ else:
+ print >>sys.stderr, _("ERROR: Processor '%s' is not supported by Karesansui.") % arch
+ ret = False
return ret
投稿者 sasapurin : 19:04
| コメント (0)
| CentOS
, Linux
, オープンソース系
| トラックバック
|