nDiki : Memcached

Memcached

設定ファイルいらずのハイパフォーマンス分散メモリオブジェクトキャッシュシステム。 PerlPHPPythonJavaRubyC#、C用のAPIが既に提供されている。

Memcachedメモリ上にキャッシュし特にファイルへ書き出したりしない。

拙作の WikiEngineWiKicker」も WikiPageHTML 変換結果を Memcached 上にキャッシュする機能を備えている。

mixiはてなブックマークでも利用されている (記事1記事2)。

スポンサード リンク

2004年1月15日 (木)

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

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

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

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

*1検索を実行するGETリクエスト用URLへのリンクがページにある

スポンサード リンク
[ 1月15日全て ]

2004年2月1日 (日)

WiKicker 0.20 リリース

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

[ 2月1日全て ]

2004年2月14日 (土)

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

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

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

[ 2月14日全て ]

2004年2月15日 (日)

[ WiKicker ] Memcachedメモリ使用量

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

[ 2月15日全て ]

2004年6月5日 (土)

[ 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 のコード自体が綺麗になったのかこれらも出なくなっていい感じ。

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
[ 6月5日全て ]

2004年7月3日 (土)

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

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

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

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

[ 7月3日全て ]

2004年7月31日 (土)

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 v5.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 が必要になった。

[ 7月31日全て ]

2004年12月31日 (金)

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

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

Web 日記DiKicker に。

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

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

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

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

SNS

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

mixi の方は結構面白い。

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

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

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

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

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

Google AdSense

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

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

cool programs

Palm OS 生活復活

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

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

http://www.naney.org/img/2004/X/X2004-03-05-0003.jpg http://www.naney.org/img/2004/X/X2004-03-14-0004.jpg http://www.naney.org/img/2004/X/X2004-04-10-0001.jpg

[ 12月31日全て ]

2006年4月30日 (日)

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

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

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

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

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

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

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

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

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

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

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

[ 4月30日全て ]

2007年4月5日 (木)

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

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

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

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

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

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

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

[ 4月5日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィの SNS の企画開発を行うグループでマネージャー・プロダクトオーナーをしています。CS 向上・ユーザーサポート・健全化などにも取り組んでいます。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.054423s / load averages: 0.52, 0.43, 0.51
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker