nDiki : Memcached

[ WiKicker ] Memcached を使った検索結果のキャッシング

WiKicker の機能のうち、ヘビーな処理が必要なものの筆頭に検索機能がある。 今のところ単純に全ページに対してマッチング処理を行うのでページ数が増えるに従い遅くなってくる。 ロボットの総ナメが怖い*1ので NaneyOrgWiki では load average が 5 を越えたら一時的に検索機能が停止するようになっている。

そこで Memcached を使って検索結果をメモリキャッシュするようにしてみた。 本当はWikiPageのパース・レンダリング結果をキャッシュして、通常のページ表示を高速化したいと考えているのだが、今はまず影響の少ないところから(何でもいいから Memcached を使ってみたいというのが本音)。

で、実装してみた。 キャッシュがヒットすればすばやくレスポンスを返せるはずなのだが...やはり微妙だな。 速くなった気もするのだが、サーバの状態によってかなり遅い時もあるようだし。 まずはこれでしばらく運用テストしてみて、効果がありそうだったら他の部分にも適用することにしよう。

WiKicker 0.20 リリース

1ヶ月ぶりにリリース。 tDiaryテーマ対応・共有メモリ使用・Memcached使用など実験的なコードを沢山いれた。

[ WiKicker ] WikiPage のHTMLレンダリング結果のキャッシュ

ようやく、HTMLレンダリング結果のキャッシュに着手。 cookie ベースでユーザ毎のカスタマイズ(名前やTZ)があるので、デフォルトのまま表示リクエストのみキャッシュが効くようにする。 キャッシュによる高速化を受けるのでは投稿してくれている常連ではなく検索エンジンから飛んできた一見さんということになるが、サーバの負荷が下がれば間接的に常連さんへのレスポンスも良くなるかと。

変換されたHTMLフラグメントをMemcachedにキャッシュ。 最初、キャッシュを有効にすると逆に遅くなってしまって「まいったな」と思ったが、リクエスト処理終了毎にdisconnect_all するようにしたら、キャッシュの効果を体感できるぐらいの速度が出るようになった。

[ WiKicker ] Memcachedのメモリ使用量

現在 NaneyOrgWiki には946のページあるのだがHTMLフラグメントをMemcachedにキャッシュさせて、メモリ使用量が 24MBぐらい(検索結果キャッシュも含まれる)。 キャッシュの expires は2時間(AutomaticLinkが無効な時にキャッシュした場合は30分)。 こんなものかな。 現在 max 32MB で Memcached を起動しているけど、20MBぐらいにして積極的に古いのは削除させてもいいかもしれない。

[ WiKicker ] キャッシュまわりにバグ

Memcached まわりをいじったので、キャッシュ具合をテストしていたら変な現象が。 WikiPage が表示されるべきところに、検索結果が表示されている。 あれ?

ページの内容が表示されるところに検索結果が

WiKicker では WikiPage のレンダリング結果も検索結果もキャッシュしているが、それぞれ別のキャッシュキーになるようにしている (WiKickerのバージョンを $V とすると、'$V:h:ページ名' と '$V:s:検索語')ので混ざるはずがないんだけれどな。 キャッシュしているデータの形式も違うし。

最初は Memcached まわりのアップデートで不具合がでたのかと思ったが、戻しても変わらない。ということは、ずっと以前からこの問題が発生していたのか。 やば。 設定でニックネームを設定している(cookie に保存している)と、その Web ブラウザに対してはキャッシュ機能が働かないようになっているので発見が遅れてしまった。

で結局コードをチェックしてみたら「WikiPage 表示と検索結果表示の View クラスを同じにしていたため、検索結果のレンダリングが WikiPage レンダリング結果と同じ領域にキャッシュされる」という風になってしまっていた。 ということで誰かがページ名で検索するとそれがキャッシュされてしまい、ページを読もうとしてもキャッシュ破棄されるまで検索結果が表示されてしまうというひどい状況になっていたと。

修正。

キャッシュキーのバグ

Memcached の出力をチェックしていたら、たまにエラーが起きていることを確認。 Memcached のプロトコルをチェックしたら、キーには制御文字と空白は使えないとある。 Cache::Memcached を見たらキーはそのまま through するだけ。 ということでページ名に空白が含まれている場合などの時には、まずい事になっていたようだ。 こちらは、キーを自前でエンコーディング(ページデータベースファイル名の作成に使っている base64 の亜種)するように修正。

Cache::Memcached 1.13 の Perl 5.005_03 対応

WiKicker で使用しているキャッシュシステム Memcached 用の Perl API Cache::Memcached が新しくなっていたので、入れ換え。

1月に入れた時と同様、Perl 5.005_03 ではそのまま動かないので一部を修正。 前回はCVSスナップショット(Memcached.pm revision 1.8)に対する修正だったので手元で修正しただけだったが、今回はパッチも作っておく。

修正点は

• our を使わないようにする。
• fields::new を代替コードに。
• IO::Handl::blocking を代替コードに。
• use bytes を使わないようにする。

といったところ(WiKicker で使っているところのみ修正)。

以前は Use of uninitialized value がかなり出ていたのだが、 Cache::Memcached のコード自体が綺麗になったのかこれらも出なくなっていい感じ。

• Cache-Memcached-1.13-5.005_03-20040605.diff
  • Cache-Memcached-1.13 ディレクトリのある場所で patch -p0 < パッチ

Memcached 1.1.11

Perl API (Cache::Memcached)のアップデートのついでに、Memcached 自体もアップデート。

 cd /tmp
 wget http://www.monkey.org/~provos/libevent-0.8.tar.gz
 tar zxvf libevent-0.8.tar.gz
 cd libevent-0.8
 ./configure
 make
 cd ..
 wget http://www.danga.com/memcached/dist/memcached-1.1.11.tar.gz
 tar zxvf memcached-1.1.11.tar.gz
 cd memcached-1.1.11
 CFLAGS='-L../libevent-0.8 -I../libevent-0.8' ./configure --prefix=$HOME/local/memcached-1.1.11
 make
 make install

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

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

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

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

Cache::Memcached 1.14 の Perl 5.005_03 対応

1.14 が 7月27日にリリースされていたのでパッチ作成。 1.13 用のパッチがあたったのでそのままいけるかなと思ったが、テストしたところまたいくつかの非互換コードが増えていたのでそれらの修正を行う。

 tar zxvf Cache-Memcached-1.14.tar.gz
 cp -a Cache-Memcached-1.14 Cache-Memcached-1.14.orig
 patch -d Cache-Memcached-1.14 -p1 \
   < Cache-Memcached-1.13-5.005_03-20040605.diff
 find Cache-Memcached-1.14 -name '*.orig' -exec rm {} ';'
 emacs Cache-Memcached-1.14/Memcached.pm
 LC_ALL=C TZ=UTC0 diff -Naur \
   Cache-Memcached-1.14.orig Cache-Memcached-1.14 \
   > Cache-Memcached-1.14-5.005_03-20040731.diff

新規修正点は

• Socket モジュールでのインポートで IPPROTO_TCP が追加になったところが実験環境でエラー。コードの中では利用していないので削除。
• ChangeLog 中の下記のため @+ を使うようになったようだが、5.005_03 では定義されていないのでエラー(perl.*delta のどこにものっていないのでチェックに苦労。perlretut に言及があって Perl 5.6.0 から提供されるようになった事を確認)。Cache::Memcached 1.13 で行っている pos を使った処理に戻す。

 2004-07-19
         * don't use pos() because it doesn't seem to work in
           taint mode.  use $+[0] instead.  (Dave Evans <..@djce.org.uk>)

それからパッチの作り方を変更。patch の man の通り LC_ALL=C TZ=UTC0 にするのとオプションを -Naur を使うように。

また 1.14 から String::CRC32 が必要になった。

• Cache-Memcached-1.13-5.005_03-20040731.diff
  • Cache-Memcached-1.14 ディレクトリのある場所で patch -p0 < パッチ

私的10大ニュース2004 [ web ]

今年の大事件、マイブームなど。

Web 日記を DiKicker に。

2月22日にハイパー日記システムから DiKicker へ移行。 自分で開発しているので好きなように改良ができて楽しい。 比較的すんなり安定したので最近はあまりコードをいじらず。

WiKicker 安定。後半は spam がひどい。

WiKicker の方も安定し、(管理をのぞいて)必要な機能もだいたい実装された感じ。 秋ぐらいから NaneyOrgWiki の方にも spam 的な書き込みが多発。 パターンによる書き込み拒否の実装で年末それなりに収束しつつある感じ。

Memcached によるキャッシュ効果は絶大だった。

SNS

orkut、mixi に登録。 前者はそれほどはまらずフェードアウト。

mixi の方は結構面白い。

• RSSを介して既存のWeb 日記(Blog)を使えた。
• 日本人中心のコミュニティ。

というのが遊んでみるのに良かった。

ついついチェックしてしまうのは

• 足あと
• 最終ログイン時刻表示
• 知人の mixi 日記

の存在。 オフィスで広まったことで楽しさも増した。

来年の今ごろも継続しているだろうか? 今後カスタマイズ機能とかが充実してくれると嬉しい。

(SNSではないが)Gmailの方は登録したけどまだ活用できていない。

Google AdSense

導入。 USの小切手からの入金用にシティバンクの口座を開いたものの、シティバンクには数ヶ月後に4拠点閉鎖の命令がくだるなど安心できない状況ではある。

私的10大ニュース2004 [ comp ]

cool programs

• pdumpfs
  • 年初に買った外付けHDDへのバックアップは Linux、Windows とも pdumpfs で。
• Memcached
  • 簡単・高速なキャッシュシステム。使える。
• Firefox
  • Galeon がだんだん使いにくくなってから Mozilla へ。その後正式リリースされた Firefox に乗り換え。
• Subversion
  • 将来的に CVS から移行する事を考えて試験的に導入。良い。Windows でも TortoiseSVN のおかげで簡単に利用できる(CVS にも TortoiseCVS が出て便利になった)。
• 影舞
  • 今年前半のプロジェクトで活躍。
• PAR
  • Windows 向けのプログラムを Perl で書いて気軽に配布できるようになった。素晴しい。wxWidgets + wxPerl を使えば Windows / UNIX のどちらでも使えるGUIアプリケーションが作れる。そういう意味で Java 以外の選択肢として選べるようになった。最も wxWidgets はまだきちんと使い込んでいないけれど。
• NSIS
  • 前述の PAR で exe 化したプログラムのインストーラを作成するのに活用。
• Template Toolkit
  • Webアプリケーション開発プロジェクトで採用。www.naney.org の静的コンテンツの生成でも使い始めた。

Palm OS 生活復活

PEG-TJ25を購入し、Palm OS 生活復活。 最初はおもちゃのつもりで買ったのだが、プロジェクトマネジメントなどにシフトした仕事のスケジュール管理などで大活躍。

PDA 市場の明るい話はあまり聞かないが、末長く製品が出て続けて欲しい。

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 過ぎだかに落ちたあとは復帰する様子がないので(管理者が落ちたかな?)、今日はあきらめ。

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

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

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

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

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

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

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