root権限、Apache 管理者権限がなくてもインストールが可能な、Perl スクリプト常駐プログラム。 Perl CGI プログラムの高速化に利用できるが、CGI プログラムに限らず通常のスクリプトの高速化にも使うことができる。
nDiki (DiKicker) も SpeedyCGI を使用している。
過去の6月30日より。
www.naney.org をホスティングしているサーバが重いと思ったら、同じサーバ上のあるユーザの CGI プログラムが5プロセス無限ループしてるっぽい……。 load average 20前後。
あおりを受けて、nDiki が大変なことになっている。
nDiki は SpeedyCGI を使っているのだが、バックエンドの speedy_backend が捌ききれず、フロントエンドの speedy が大量に待ちに入ってしまっている。
MaxBackends を調整しても駄目(下手にバックエンドプロセス数を増やしても、結局処理が追いつかない)。
ということで急遽対策。
load average が高い時には、はてなブックマーク上の検索結果を表示させるために行なっているはてなブックマークへのアクセスを休止するように変更。 24時間に設定してあるキャッシュの有効期限が切れていても、高負荷の時にはアクセスにいかないようにする。
これで DiKicker の処理時間を短縮。相手側サーバへの負担も軽減。
おかげ様でここ最近 nDiki の RSS へのアクセス数が増えてきている。 ありがたい事である。
しかしながら DiKicker の RSS レスポンスは、あまり賢くなく毎回データベースから最新記事情報を抽出して生成しているため、それほど処理が速くない。
なのでアクセス頻度を高くしている RSS リーダがどこかで同時に起動しているとちょっとしんどい。 特にここ最近 Google Desktop からのアクセス数が増えている感じ。
さすがに今日はサーバの負荷が高く処理が追いつかなくてどうしようもないので、一時的に Google Desktop を拒否することに。
.htaccess に設定を追加。
BrowserMatch "Google Desktop" denybrowser deny from env=denybrowser
近日中に、RSS 処理を改善してすぐに解除する予定。
効果があるかどうかは不明だが、Crawl-delay: に対応するというクローラ (Slurp、msnbot) 向け設定を追加。
User-agent: Slurp Crawl-delay: 20 User-agent: msnbot Crawl-delay: 20
アクセス数としては Googlebot と Slurp がダントツ。 しかし Google は無下にする訳にもいかないしなぁ。
朝 www.naney.org の過去記事を確認しつつ作業をしていたら、9:00 前に急にアクセスできなくなった。 ping も通らない。 9:20 ぐらいに 1度復帰したが、また10:00 前にダウン。
それから何度も落ちては復帰を繰り返すようになってしまっている。 SSH で接続している途中にも突然刺ささるし、傍から見ていても原因が良くわからない。
昨日 WiKicker をアップデートしたから「もしかしてうちが原因?」とちょっと心配もしたりするのだが、無限ループに入ったりメモリを使い尽すようなコードが追加してはいないはずだしなぁ(ローカルでのテストではそのような現象は見られない)。
落ちる直前まで見ていてもそれほど load average が高いわけでもないようだしなぁ。
とまぁ、しばらく様子を見ているうちに NaneyOrgWiki と nDiki が Internal Server Error。 止められた。 正確には SpeedyCGI のフロントエンド speedy コマンドの実行権限を管理者に落とされた。
ということもあって疑われたと推測。
一応こちらでも SpeedyCGI を使わないで直接 Perl で実行するように変更してみたり、Memcached を起動するのをやめてみたりなど設定を変更してみたりするのだけれど、関係なく落ちる落ちる。
管理者がシステムの設定を変えていないで発生するようになったのなら、ハードウェア障害が起きているんじゃないかと想像してしまうのだが、実際どうなんだろうか。
結局夜 23:00 過ぎだかに落ちたあとは復帰する様子がないので(管理者が落ちたかな?)、今日はあきらめ。
WiKicker ベースのシステムが稼働しているホストが FreeBSD 5.2.1-RELEASE から FreeBSD 6.1-RELEASE に更新されるのにともない、再インストール作業を行った。
動作確認をしたところ CGI プログラムは動くものの Perl モジュール中の DATA セクションが読めていないようなエラー表示がされた。
もしやと思い SpeedyCGI を外したら正常動作。
SpeedyCGI 下で動くことを考えて、DATA セクションを1度しか読まないようにコーディングしてあるはずなのだが、はて。
他の作業もあり細かいチェックができなかったのでもしかしたら違うところでの問題かもしれないが、ちょっと厄介。
www.naney.org がどうもまた最近重い。
load average が 30 前後まで上がっている。 しばらくするとだんだん落ちついてくるのだが、3 以下になったところでまた 30 前後までまた一気に上がるというのを繰り返している。 load average で振る舞いを変えるのは WiKicker / DiKicker の特徴なので、これはうちが原因かも。
調べてみると SpeedyCGI のフロントエンドのプロセスが順番待ちで大量に起動している。
どうやら先日追加した自動リンクの機能改善にかかわるコード修正による、若干の処理速度の低下がまずいようだ。
速度が上がるようにちょっと修正してみたけれどまだ駄目なようなので、しかたなく単語の連接チェック部分を一時コメントアウトして対応。
今後、自動リンクまわりの更なる高速化がする必要がありそう。
www.naney.org を収容しているサーバの負荷が高い状態。
という対処をしたけれどそれでもなかなか負荷が落ちつかない。
傾向としては SpeedyCGI のバックエンド側(speedy_backend)が MaxBackends まで起動して処理が追いつかないと、起動しているフロントエンド側 (speedy) がどんどん増えてしまうという状況のようだ。
DiKicker の高速化も順次着手しているのだけれど追いつきそうにもないので、loave average が高い時は頑張らずに無条件に 503 を返すように修正して対応(以前ハイパー日記システムの時にも同じことをした)。
本当は SpeedyCGI フロントエンドの数に応じて負荷の軽い処理に切り換える等工夫したいんだけれど、フロントエンドの数を取得する方法は簡単にはなさそうなんだよなあ。
naney.org メールサーバの移転に次いで、Web サーバの移転作業。
現行 Web サーバと Unison でファイル同期している Web コンテンツを、さくらのレンタルサーバへ Unison でファイル同期。
nDiki 用に DiKicker (WiKicker) を make install。
%bash $perl -MCPAN -e mkmyconfig $perl -MCPAN -e shell o conf makepl_arg PREFIX=/home/naney/local/WiKicker o conf mbuildpl_arg --install_base=/home/naney/local/WiKicker o conf commit notest install CGI::SpeedyCGI $tar zxvf WiKicker-0.420.tar.gz $cd WiKicker-0.420 $export PERL5LIB=$HOME/local/WiKicker/lib/perl5/site_perl/5.8.9 $perl Makefile.PL PREFIX=$HOME/local/WiKicker $make $make install
以前きっちり Module::Install で Makefile.PL を作っておいたおかげで、比較的スムーズにインストールできた(自画自賛)。
ちょっとはまったところは CGI::SpeedyCGI の make test を実行する(される)と SSH 接続がサーバ側から切られてしまうという現象にあったところ。 テスト用に大量にスクリプトが起動されるの検出して自動的に kick されたのだろうか。
さくらのレンタルサーバでは .htaccess Options が使えないようなので削除。 ExecCGI や MultiViews が有効になっているようなので問題なし。
Perl 5.005_03 用に書いてあったスクリプトについて、Perl 5.8.9 で文字化けしないように utf8 まわりを修正。
1時間毎に実行したい処理を列挙するシェルスクリプトを1つ作って、コントロールパネルから1時間毎に実行するように設定。
現行サーバでは任意の crontab を設定できたので、1時間毎はちょっと物足りない。 おいおい負荷にならない範囲で、外部から定期的に HTTP アクセスして処理を定期的に実行できるようにもするかな。
まだ動いていないスクリプトもあるけれど(大きいところだと NaneyOrgWiki (Wiki))現行サーバの解約日もせまっているので、サーバ移転させてしまうことに。
VALUE-DOMAIN で DNS サーバ設定を変更し www.naney.org でさくらのレンタルサーバにアクセスできるように A レコードを変更。
今のところ特に重い等もなく順調。 現行サーバでは深夜非常に重くなる時間帯があったのだが、それが無くなるのが嬉しい。 また容量が100MB*1から10GB*2になったので心理的にセーブしなくて良くなった。
年内に移行できて良かった良かった。
[ さくらのレンタルサーバ プレミアム ]
さくらのレンタルサーバの「ディスク容量増量ならびにOSバージョンアップに伴うメンテナンス」が寝ている間に終了。 Perl も新しいバージョンが使えるようになるのだけれど、デフォルトでは今までと同じバージョンだから何もしなくても良いはず。
って確認したらスクリプトが動かなくなっている……。
あー 32 bit が 64 bit になったんだっけ。 SpeedyCGI が動かなくなっているのでまず外し。で再度走らせたら今度は Storable が Long integer size is not compatible といって既存データを読めなくなったので破棄して再生成中。あとは別のスクリプトでいくつか動かなくなったものがあったので、そちらは依存ライブラリを cpanm しなおし。
それとそれと
メールの送信前認証としてご提供している POP before SMTP を廃止いたします。そのため、今後はSMTP認証(SMTP-AUTH)が必須となります。
ってあったのでメールの方も確認したら Gmail からさくらのレンタルサーバ経由でメールが送れなくなっている。あーでも POP before SMTP なんか使ってなかったでしょう。なんでだー。って Twitter あたりみたら、どうも「国外IPアドレスフィルタ」(デフォルト有効)の機能提供開始のせいっぽい。 Gmail のサーバ国内とは限らないもんねぇ。
開始日時は自分のサーバは3月19日(水) 12:00 なので、この時から既に送れない状態になっていたのか。1週間気がつかなかったとか、もうプライベートではメールの利用頻度下がっているってことだねぇ。
さて、国外IPフィルタを無効化。
今日は朝からホットだった。
Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。