mixiがはまったmemcached(or libevent?)の問題を調べる人たち
memcachedを1.2.8にバージョンダウンしたら、安定したっぽい。libeventは1.4系最新の1.4.14b。1.4系から入ったマルチスレッド対応周りでバグがあるんじゃないかと予想。
2010-08-13 18:10:26クライアントを50台ぐらい用意したら、けっこうな頻度で再現したので、効率的に解析するにはクライアント数を増やしたほうがよさそう / mixi Engineers’ Blog » mixi大規模障害について http://htn.to/brjqHP
2010-08-13 18:19:30突然終了って、exit してるのかシグナルくらってるのかどっちなん? / mixi Engineers’ Blog » mixi大規模障害について http://htn.to/HqYJDY
2010-08-13 18:25:56@kazuho main()にあるevent_base_loop()を抜けてexit(0);してます。 suid_dumpableは1です。
2010-08-13 18:36:24これやってほしい... RT @kazuho: 自分が触れる環境ならループ抜けるタイミングにブレークポイントかけてコアとって解析してくんだろうな… お疲れであろう中の人には失礼だけど、こういう障害解析好き
2010-08-13 18:52:18@kzk_mover (たぶん)同じです。memcached.cのevent_base_loopを抜けちゃってるのが確認できてます。
2010-08-13 19:04:40これデフォルト設定(-c 1024)のmemcachedに2-3プロセスぐらい起動すれば数分で落とせる http://gist.github.com/522741
2010-08-13 20:50:42落ちるのこれ 最新版でも起きるそうです http://twitter.com/stanaka/status/21037070317
2010-08-13 21:05:55前言撤回で、コネクション万単位じゃなくても起きる。接続数限界になってる時に大量にコネクション接続切断繰り返すと落とせる。ただ1000コネクションでもあんまり無いレベルだからそうそう起きることではない。
2010-08-13 21:11:30まあコネクション数足りなくなってたらパフォーマンスに影響出るだろうから、そこら辺監視して-c増やすなりクライアント絞るなりしてれば起きない
2010-08-13 21:16:56挙動はほぼ把握。memcachedのメインスレッドのイベントキューには、listenとタイムアウトのイベントがのっていて、高負荷になるとタイムアウトイベントの再挿入に失敗する様子。とりあえずはevent_base_loopを再実行すれば良さそうだけど、正しい対処かは不明
2010-08-13 21:43:55コネクションの接続切断のコストは高く、高負荷になるとさばききれずにキューに処理が溜っていって、タイムアウトイベントの満了後、再挿入処理の前にキューのイベント数判定ロジックが走って、event_base_loopが終了してしまう、ということらしい。
2010-08-13 21:48:26挙動は分かって暫定対処方法も分かったけど、libeventの仕様を良く理解していないので、どのようにするのが筋が良い対処かは分からない。これ以上は、ちょっと勉強が必要
2010-08-13 21:53:11@stanaka event_base_loopの再実行というアイディアは出たのですが、そもそもそれは根本解決ではないのでは?かと。今回の件は奥が深いですよね・・・
2010-08-13 22:11:12イベント駆動プログラミングを学ぶことによって、負荷の再現のために5000forkして自宅サーバー落としたり、クラウド破産したりするリスクを軽減することが出来る。
2010-08-13 22:57:15event_queue_removeのエラーが出る原因分かったかも. 脳内シミュレーションが合っていれば. @bulkneets 御大の再現プログラムを使ってみるかなあ.
2010-08-14 02:10:20