nDiki : SpeedyCGI

過去の今ごろ

過去の6月30日より。

• AutoLoader に手を出す
  • SpeedyCGI を使ってスクリプトを使い回しているので、AutoLoader で徐々にローディングされた方が最初の実行での処理が短くなって良いのではないかと。きちんと評価したわけではないので実際のところは不明。

[ WiKicker ] 分あたり100アクセスオーバー

たまにあるテレビ放送後の猛烈アクセス。

RecentLogでチェックしてみたところ、1分あたりの処理数が100を超えていた。 ここ最近は、いっても40台だったから驚き。

レスポンスは悪かったものの load average は極端には上がっていなかった。SpeedyCGI のパラメータの調整がいい感じだったようだ。 ほとんど(編集ではなく)閲覧のみのアクセスだったことで、Memcached によるキャッシュもかなり有効に働いていたと思われる。

過去の今ごろ

過去の10月16日より。

• Sys::CpuLoad
  • SpeedyCGI 下だったら使った方が平均的には速いかも。

サーバ高負荷状態につき DiKicker 機能修正とサーバ設定変更

www.naney.org をホスティングしているサーバが重いと思ったら、同じサーバ上のあるユーザの CGI プログラムが5プロセス無限ループしてるっぽい……。 load average 20前後。

あおりを受けて、nDiki が大変なことになっている。

nDiki は SpeedyCGI を使っているのだが、バックエンドの speedy_backend が捌ききれず、フロントエンドの speedy が大量に待ちに入ってしまっている。

MaxBackends を調整しても駄目(下手にバックエンドプロセス数を増やしても、結局処理が追いつかない)。

ということで急遽対策。

高負荷時にはてなブックマークへのアクセスを停止

load average が高い時には、はてなブックマーク上の検索結果を表示させるために行なっているはてなブックマークへのアクセスを休止するように変更。 24時間に設定してあるキャッシュの有効期限が切れていても、高負荷の時にはアクセスにいかないようにする。

これで DiKicker の処理時間を短縮。相手側サーバへの負担も軽減。

Google Desktop からのアクセスを一時的に拒否

おかげ様でここ最近 nDiki の RSS へのアクセス数が増えてきている。 ありがたい事である。

しかしながら DiKicker の RSS レスポンスは、あまり賢くなく毎回データベースから最新記事情報を抽出して生成しているため、それほど処理が速くない。

なのでアクセス頻度を高くしている RSS リーダがどこかで同時に起動しているとちょっとしんどい。 特にここ最近 Google Desktop からのアクセス数が増えている感じ。

さすがに今日はサーバの負荷が高く処理が追いつかなくてどうしようもないので、一時的に Google Desktop を拒否することに。

.htaccess に設定を追加。

 BrowserMatch "Google Desktop" denybrowser
 deny from env=denybrowser

近日中に、RSS 処理を改善してすぐに解除する予定。

robots.txt に Crawl-delay: を追加

効果があるかどうかは不明だが、Crawl-delay: に対応するというクローラ (Slurp、msnbot) 向け設定を追加。

 User-agent: Slurp
 Crawl-delay: 20

 User-agent: msnbot
 Crawl-delay: 20

アクセス数としては Googlebot と Slurp がダントツ。 しかし Google は無下にする訳にもいかないしなぁ。

www.naney.org サーバ断続的にダウン

朝 www.naney.org の過去記事を確認しつつ作業をしていたら、9:00 前に急にアクセスできなくなった。 ping も通らない。 9:20 ぐらいに 1度復帰したが、また10:00 前にダウン。

それから何度も落ちては復帰を繰り返すようになってしまっている。 SSH で接続している途中にも突然刺ささるし、傍から見ていても原因が良くわからない。

昨日 WiKicker をアップデートしたから「もしかしてうちが原因?」とちょっと心配もしたりするのだが、無限ループに入ったりメモリを使い尽すようなコードが追加してはいないはずだしなぁ(ローカルでのテストではそのような現象は見られない)。

落ちる直前まで見ていてもそれほど load average が高いわけでもないようだしなぁ。

とまぁ、しばらく様子を見ているうちに NaneyOrgWiki と nDiki が Internal Server Error。 止められた。 正確には SpeedyCGI のフロントエンド speedy コマンドの実行権限を管理者に落とされた。

• (大半はロボットによるものなのだけれども) NaneyOrgWiki と nDiki のどちらか(あるいは両方)に常にアクセスがあってスクリプトが動いている
• top すると他のユーザの CGI プログラムは 'perl' か 'perl 5.00503' と表示されるのに対し、これらは speedy、speedy_backend と表示されるため、管理者の目を引きやすい

ということもあって疑われたと推測。

一応こちらでも SpeedyCGI を使わないで直接 Perl で実行するように変更してみたり、Memcached を起動するのをやめてみたりなど設定を変更してみたりするのだけれど、関係なく落ちる落ちる。

管理者がシステムの設定を変えていないで発生するようになったのなら、ハードウェア障害が起きているんじゃないかと想像してしまうのだが、実際どうなんだろうか。

結局夜 23:00 過ぎだかに落ちたあとは復帰する様子がないので(管理者が落ちたかな?)、今日はあきらめ。

SpeedyCGI 以下で WiKicker がうまく動かない?

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 のフロントエンドのプロセスが順番待ちで大量に起動している。

どうやら先日追加した自動リンクの機能改善にかかわるコード修正による、若干の処理速度の低下がまずいようだ。

速度が上がるようにちょっと修正してみたけれどまだ駄目なようなので、しかたなく単語の連接チェック部分を一時コメントアウトして対応。

今後、自動リンクまわりの更なる高速化がする必要がありそう。

サーバの負荷が高くなったら DiKicker が 503 を返して沈静化を待つようにした

www.naney.org を収容しているサーバの負荷が高い状態。

1. Referer spam 弾きを強化。
2. 1日半前ぐらいに1度リブートしたようで、Memcached が起動していなかったので起動。

という対処をしたけれどそれでもなかなか負荷が落ちつかない。

傾向としては SpeedyCGI のバックエンド側(speedy_backend)が MaxBackends まで起動して処理が追いつかないと、起動しているフロントエンド側 (speedy) がどんどん増えてしまうという状況のようだ。

DiKicker の高速化も順次着手しているのだけれど追いつきそうにもないので、loave average が高い時は頑張らずに無条件に 503 を返すように修正して対応(以前ハイパー日記システムの時にも同じことをした)。

本当は SpeedyCGI フロントエンドの数に応じて負荷の軽い処理に切り換える等工夫したいんだけれど、フロントエンドの数を取得する方法は簡単にはなさそうなんだよなあ。

www.naney.org をさくらのレンタルサーバへ移転

naney.org メールサーバの移転に次いで、Web サーバの移転作業。

静的コンテンツのアップロード

現行 Web サーバと Unison でファイル同期している Web コンテンツを、さくらのレンタルサーバへ Unison でファイル同期。

WiKicker のインストール

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 の修正

さくらのレンタルサーバでは .htaccess Options が使えないようなので削除。 ExecCGI や MultiViews が有効になっているようなので問題なし。

いつくかのスクリプトの修正

Perl 5.005_03 用に書いてあったスクリプトについて、Perl 5.8.9 で文字化けしないように utf8 まわりを修正。

cron 設定

1時間毎に実行したい処理を列挙するシェルスクリプトを1つ作って、コントロールパネルから1時間毎に実行するように設定。

現行サーバでは任意の crontab を設定できたので、1時間毎はちょっと物足りない。 おいおい負荷にならない範囲で、外部から定期的に HTTP アクセスして処理を定期的に実行できるようにもするかな。

DNS 設定変更

まだ動いていないスクリプトもあるけれど(大きいところだと NaneyOrgWiki (Wiki))現行サーバの解約日もせまっているので、サーバ移転させてしまうことに。

VALUE-DOMAIN で DNS サーバ設定を変更し www.naney.org でさくらのレンタルサーバにアクセスできるように A レコードを変更。

今のところ特に重い等もなく順調。 現行サーバでは深夜非常に重くなる時間帯があったのだが、それが無くなるのが嬉しい。 また容量が100MB*1から10GB*2になったので心理的にセーブしなくて良くなった。

年内に移行できて良かった良かった。

---

[ さくらのレンタルサーバ プレミアム ]

今日のさえずり - チョコレート臭のするリップクリーム塗られた

2009年12月22日

• 09:36 東京水のお父さん若すぎ。娘はいくつの時の子だ?
• 09:46 今年もビックカメラでカレンダーご自由にお持ちくださいになってるな。これって例年通り1枚もの? 車窓から見下ろしているからよくわかんない。 L:有楽町駅
• 11:20 カシオ計算機株式会社の高精度計算サイト keisan で二項分布のグラフチェックしている。このサイト便利だな。 http://bit.ly/6H554E
• 11:36 やはり結果が二項分布になっていなかったのは毎回 new System.Random().NextDouble() されていたからだな。1つの Random オブジェクトを使うように修正しておく。
• 12:32 清まる東京ミートレア店のチラシに「住所かけ」と @nyafuru に指示された。
• 12:34 泣く泣く書いた。 QT @Naney: 清まる東京ミートレア店のチラシに「住所かけ」と @nyafuru に指示された。
• 12:45 2009年12月18日の歩行: 5898歩、4.54km、51分、5.29km/h、消費 224.9kcal、脂肪燃焼 32.1g、3.3エクササイズ。
• 12:46 2009年12月19日の歩行: 3750歩、2.88km、34分、5.05km/h、消費 146.9kcal、脂肪燃焼 21.0g、2.0エクササイズ。
• 12:48 2009年12月20日の歩行: 569歩、0.42km、5分、4.48km/h、消費 21.6kcal、脂肪燃焼 3.1g、0.3エクササイズ。
• 12:49 2009年12月21日の歩行: 8585歩、6.60km、73分、5.37km/h、消費 337.8kcal、脂肪燃焼 48.2g、5.0エクササイズ。
• 13:02 今日は窓ガラス清掃の日か。
• 15:15 何でダイワハウチュなんだ? - デスクトップジーヴォβ http://bit.ly/4n80D1
• 17:03 歯医者なのでそろそろ会社出ます。
• 17:27 ヨドバシカメラで同時プリント回収。
• 18:21 歯医者行ってくる。
• 18:27 歯医者到着。腹減った。
• 19:01 歯の定期健診終わり。なんかチョコレート臭のするリップクリーム塗られた。
• 19:03 少し歯石があるぐらいで良く歯磨きできているとのこと。
• 19:06 デンタルフロスほとんどサボっていたので気になっていたが問題なし。その事について聞いたらできればしてくださいと苦笑いされた。
• 24:19 さくらのレンタルサーバに WiKicker インストール中。
• 25:48 さくらのレンタルサーバで DiKicker を動くようにした。サーバ移転してもこれでとりあえず nDiki は維持できそう。
• 25:51 さくらのレンタルサーバで CGI::SpeedyCGI を make test すると途中でサーバ側から SSH 接続切断される。テストで大量にプロセスが起動されるのでそれで切断されちゃうのかな。
• 26:55 寝る。

2009年12月23日

• 12:47 ヒンジカバー装着。ストレージクリップがとまりにくくなったけど、まずまず。
• 14:15 これからケーキのデコレーションするよ。
• 15:13 デコった。 http://movapic.com/...
• 16:27 ケーキ食べたし次、肉調達してくる。
• 16:38 今年は近所の肉屋開いてた。ローストチキン確保。
• 18:52 うちで @nyafuru のスヌーピーアイコンが好評。
• 24:35 MovaTwitter クリボー(メモ帳) の RSS フィードがいつの間にか無くなっている。利用していたので残念。 #movatwi
• 24:54 A レコードを変更して Web サーバも新サーバに移行。

さくらのレンタルサーバのバージョンアップメンテナンス

さくらのレンタルサーバの「ディスク容量増量ならびに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フィルタを無効化。

今日は朝からホットだった。

今日のさえずり: 国外 IP アドレスからのアクセスブロックのせいか

• 07:38 さくらのレンタルサーバの「ディスク容量増量ならびにOSバージョンアップに伴うメンテナンス」が寝ている間に終了。って確認したらスクリプトが動かなくなっている……。
• 08:11 Perl のバイナリが変わったので動かなくなった SpeedyCGI をいったん外した。
• 08:13 あと 32 bit が 64 bit になって Perl の Storable が Long integer size is not compatible といって既存データを読めなくなったので破棄して再生成中。
• 09:29 あー、Gmail からさくらのレンタルサーバ SMTP サーバ経由で送れなくなったのメンテのせいじゃなくて、国外 IP アドレスからのアクセスブロックのせいか。