博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

[zz]日本最大sns站点mixi因memcached bug引起长时间的宕机

Posted on 2011-09-26 14:27  wangwangkunkun  阅读(384)  评论(0)  编辑  收藏  举报

http://askmoon.blog.51cto.com/2416695/494369

日本最大sns站点mixi因memcached bug引起长时间的宕机

2011-02-15 13:59:48

标签：mixi memcache memcached sns

今年的8月10日，日本的最大sns站点mixi因memcached引发的宕机，mixi拥有日本最大的memcached集群，共100多台 memcached服务器，他们工程师设计的架构即使宕机其中的十几台都不影响正常的业务。事情的经过时这样的，17点20分左右系统出现大量的 memcached服务器memcached直接异常结束，当初他们的工程师也没有想到是由memcached本身的bug引起，memcached服务器一直运行得很好，在这情况下，他们的技术团队，4个人，主要负责人开始分析memcached代码，一个开始进行系统恢复，另外2个人开始查找替代 memcached，采用其它cache的方法。23:30分左右，由于整个系统访问量下降，全部恢复完毕，第二天11点20分左右，随着访问量上增大，又发生宕机，11日晚22点50分左右，找到memcached bug，并修护，12日凌晨1点50分左右全部恢复完毕。
事后，通过其官方blog写了3篇文章进行详细的分析，并把分析的结果提交到memchaed邮件组，提交了相关patch及问题重现的程序。
事情的大概原因是，mixi使用的memcached服务器版本为memcached-1.4.4 + libevent-1.3b，他们设置了memcached的最大连接数为30K,当连接数超过30K以后，memcached的工作线程跟主线程发生资源竞争，主线程跟工作线程同时访问和修改主线程的event_base，从而引起内存破坏，导致memcached进程异常终止。mixi给出的建议，监控最大连接数目，当快到达最大数，切换到其他的memcached服务器上，使用memcached proxy或者采用memcached udp协议可以完全避免memcached宕机的可能，同时启动memcached时带一个-l的选项，可以在超出连接限制的情况下，memcached 输出Too many open connections，memcached进程而不宕机。
从这件事情的本身来看，memcached部署量这么大，还有存在大的bug，各个技术团队更应该加强自身的团队得技术建设，同时也感慨国外企业能第一时间把自身宕机的原因进行详细的分析，并分享出来，这样的宕机案例，比分享一个成功的案例，更难得。笔者在使用日文进行搜索了一下，在这个事情的解决过程中，mixi团队通过twrite跟外部进行沟通，得到了外部大量的问题分析和建议。

0人

了这篇文章

类别：缓存┆技术圈(0)┆阅读(65)┆评论(0) ┆ 推送到技术圈┆返回首页

上一篇 让memcached和mysql更好的工作 下一篇 memcache@facebook

相关文章