mixiがはまったmemcached(or libevent?)の問題を調べる人たち
-
- いいね！31
Kazuki Ohta
@kzk_mover
@stanaka またソースレベルでの解析メモを書いてみました. stanakaさんの解析メモも有ると嬉しいかもです！特に再現時の変数の値など... > http://bit.ly/bPXPPt
2010-08-14 05:03:32
mala
@bulkneets
とりあえずmemcached導入を検討している人向けの情報としては滅多に起きることではない。すでに稼働させている人向けの情報としては想定してる最大接続数に合わせて-c増やすかmemcachedの台数増やしておけば問題起きない。
2010-08-14 10:32:59
Shinji Tanaka
@stanaka
どうもlibeventのマルチスレッド対応が不完全なのが原因のようです。base->count++としているあたりを__sync_add_and_fetchに置きかえたら落ちなくなりました。 @kzk_mover @nealsato http://htn.to/DyePLE
2010-08-15 01:15:39
Shinji Tanaka
@stanaka
でも、libevent-1.4.14bにすると「[err] event_queue_remove」のエラーで落ちるので、こちらは別件くさい。memcached-1.2.8にすると落ちなくなるので、libeventのマルチスレッド対応は不完全、ということでFAかな..
2010-08-15 01:21:05
Shinji Tanaka
@stanaka
libeventのスレッドセーフが信頼できないとなると、event_queue_removeのエラー原因もキュー操作だろうあたりと付けて対処してみたら、だいぶ落ちなくなった。けどまだ落ちる時もあるので漏れがあるみたい / gist: 5… http://htn.to/Fqonaa
2010-08-15 02:38:43
Shinji Tanaka
@stanaka
@kzk_mover -t 1にしても、worker threadが1つになるだけで、内部的に他にもスレッドが動いているので同じ挙動になりますね。ひとまず、落ちなくなるようなパッチを作ってみようと思ってます。
2010-08-15 03:14:30
Kazuki Ohta
@kzk_mover
@stanaka なるほど、他のスレッドは統計用ぐらいかと思っていました。ひとまず、 libevent 1.4.14b + memcached 1.4.5 -t 1 の条件で僕も追って見ます。
2010-08-15 03:18:52
Shinji Tanaka
@stanaka
@kzk_mover worker threadとは別にポートをlistenしているthreadがいて、クライアントが接続するとそのthreadから適当なworker threadにソケットのfdが渡されるのですが、この受け渡しのあたりでバグってそうです。
2010-08-15 03:25:32
mala
@bulkneets
ユーザーの1リクエスト単位でコネクション維持する場合は、平均でそのリクエストに必要なmemcached台数だけコネクション保持するが、アプリケーションプロセスに対して永続化してる場合は最大でそのプロセスから接続しうるmemcached台数分のコネクション保持することになる
2010-08-15 10:37:34
mala
@bulkneets
アプリケーションプロセスが1000以下なら全台のmemcachedにコネクション張りっぱなしになったとしても(1プロセスから同じmemcachedに複数コネクション張って無ければ)デフォルト設定でもコネクション数足りてる
2010-08-15 10:43:54
mala
@bulkneets
うちの場合サービス毎にmemcached用意してるから問題にならないな。例えば全サービスから参照されるmemcachedがあったらコネクション数の問題が発生するはず。接続するアプリケーションプロセスがn万単位 + -cの数値より大きい、ならリクエスト毎に切断すべき。
2010-08-15 10:52:04
mala
@bulkneets
なにがいいたいかというと永続化してる前提ならmemcachedの台数増やすだけでは解決しないってことね(アプリケーションプロセス数*memcached台数分だけコネクション張られるので)
2010-08-15 11:04:05
埼玉の猫
@shmorimo
timer eventを人為的に殺すと高い確率で落ちる。timer と listenの両方が落ちるとmemcache終了。 timerが落ちるといずれlistenも落ちる。listenだけ落ちるとと負荷が下がるのでtimerは落ちず、acceptもしないので止まったように見える
2010-08-16 15:11:23
Shinji Tanaka
@stanaka
期待! 結局libevent側の問題だとほぼ確信できたので、後でlibeventのMLにパッチ投げます RT @shmorimo: @stanakaさんの http://htn.to/DyePLE を当ててテスト中
2010-08-16 17:56:15
Kazuki Ohta
@kzk_mover
やべえ mixi から redbull 24 本、会社に届きましたｗ 大変、有難うございます！ gkgk #redbulljp
2010-08-16 18:16:15
埼玉の猫
@shmorimo
-c 50万でテストしたところ 32万接続あたりで頭打ちとなりました。0x4ffffになにか制限がある模様。頭打ちとはなりましたがmemcachedは機嫌良く動いています
2010-08-16 18:24:29
Neal Sato
@nealsato
np! Thanks for your help! あと、 @stanaka さんにも送ったのですが、在庫がないので8/20到着予定です。 RT @kzk_mover: . @nealsato redbull届きました、有難うございますｗ
2010-08-16 18:59:13
埼玉の猫
@shmorimo
接続数MAXのときのqueue操作に問題がある可能性が超濃厚。 念のため -c 35万に80サーバー x 4fork x 1000コネクションの32万コネクションで一晩動かして帰る
2010-08-16 19:06:13
llamerada
@llamerada
mixiのmemcached問題。少しおっかけてみたけどマルチスレッド環境下でのlibeventの使い方に問題があるみたい。どうようの race condition が chromium で報告されているっぽい。 http://bit.ly/9RsLxw
2010-08-16 23:56:04