BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

MongoDB创始人Eliot Horowitz分析FourSquare宕机原因

| 作者 郑柯 关注 3 他的粉丝 发布于 2010年10月10日. 估计阅读时间: 5 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

上回书我们提到:10月4日、5日,由于数据碎片化和监控不力的原因,FourSquare经历两次宕机。FourSquare使用的后台数据库为MongoDB,在问题解决后不久,MongoDB的开发公司10gen的CTO和联合创始人Eliot Horowitz也在mongodb-user这个Google邮件组里分析了整个过程。国内知名技术博主、医药生命科学网站丁香园CTO冯大辉翻译了Eliot的分析,本着不重复发明轮子的原则,本文将引用冯大辉先生博客的主要内容,全文请见冯大辉的博客——《FourSquare长达11小时的宕机》

在冯大辉看来,Eliot的说明“有为MongoDB辟谣的意味在里面”,同时他也认为这个案例“是一个很好的研究样本,值得分享”。

为了提高响应速度,Foursquare 使用 MongoDB 存储 Check-in 的数据已经有一段时间了。这部分数据的数据库起初跑在一个 66GB 内存的 Amazon EC2 单实例上(全部在内存里),两个月前,出于对容量增长的考虑,迁移到两台 Shard 集群上。每个 Shard 机器都是 66GB 内存,为了冗余,每个 Shard 都有复制到 Slave 实例。迁移的目标是所有的 Check-in 数据都保存在内存中。数据根据 ID 分成 200 个 Shard 分片,两台机器各占一半,也就说联机数据在每台机器上各使用 33GB 的内存。两个月相安无事。

问题来了,因为 Shard 算法导致的数据分散不均衡,其中一台(Shard0)数据增长到 67GB(另外一台 50GB),超过了 66GB 的限制,读写部分分散到磁盘上,性能急剧下降。从而,网站宕机。

首先尝试增加第三台 Shard 机器,上线后开始迁移,读取从三台进行,Shard0 的数据迁移到 5% 的时候,但是写操作还是让 Shard0 宕机了。这个时候发现Shard0 存在数据碎片(data fragmentation),即使数据迁移走,还是会占用原来的内存。每个Check-in 文档大约占用 300 字节,而 MongoDB 是 4KB 的页(Page),也就说十几个文档会填满一个页,而迁移 5% 反而造成了页更加稀疏,并不是将页全部删除。

这个时候已经到了第二天,随着网站全面宕机,技术团队开始用 MongoDB 的 repairDatabase() 功能来对数据库进行压缩,因为数据库太大和 EBS 慢,也因为 repairDatabase() 不能充分利用多核CPU 的能力,这个过程耗费了 4 个小时。之后这 5% 的内存空间终于释放出来,系统重新上线。

随着 Shard0 修复,第三台成功上线,进而添加了更多的 Shard 服务器,现在数据已经更加的均衡,通过在Slave上运行 repairDatabase(),然后将其切换到 Master ,每台 Shard 内存占用缩减到 20GB左右。整个故障时间已经延续了 11 小时之多。

产生问题的主要原因就是系统过载,前面介绍每台 Shard 承载原来 50% 的压力,到了问题发生的时候,单台 Shard 的负载已经超过 Shard 之前的系统负载,这时候已经积重难返了,在容量的临界点增加新系统资源,必然导致更多的停机时间。暴露了 Foursquare 团队在容量规划方 面的不足之处,或许也因为业务增长太快了吧。另外,内存碎片化的问题在没有宕机之前,技术团队应该没考虑过这个问题,如果文档的大小超过 4K,碎片化问题就不严重了,这是特定应用场景造成的特定问题。10Gen 现在已经着手研究如何进在线压缩(online compaction)。再次,Shard 键值的顺序和插入顺序是不同的,这造成了迁移数据的时候 Chunk 的迁移不是连续的。

冯大辉认为这个案例能够带给我们很大启示:

最近 NoSQL 已经成为一个热词,类似 MongoDB 这样的新事物当然值得尝试,但是不能冒进,因为驾驭起来并非易事。仅仅能够使用是不够的,系统没出问题一切都好,一旦出了异常,有足够的技术力量(设想一 下 Foursquare 得不到 10gen 团队的支持会如何?) 支持么?在极端情况下如何控制? 如果回答不了这个问题,那么还应该暂缓。最好的办法就是..."等待"。

作为InfoQ的读者,您是这么看么?这个案例对您有何启示?欢迎在下面留下您的想法。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

发现一个错字 by 典 刘

“两台机器各占一般”

反思开源与新技术 by 王 磊

NoSQL是一门新技术,而MongoDB又是一个开源的产品,新技术和开源确实是不容易驾驭的,没有足够的经验可以借鉴,没有足够的强大的技术团队给予支持,都是他们固有的问题。但是新技术和开源也有先天的优势,开发人员众多,低成本等等。建议还是要勇于实践,从小应用开始积累经验,慢慢向大规模使用前进。

Re: 发现一个错字 by 熊 小

已经修改,多谢提醒!!!

其实 by 黄 超

冯大辉的这个“启示”其实没有什么意义

Re: 其实 by ma lionbule

冯大辉的这个“启示”其实没有什么意义

你的结论太武断了。

这次事件能导致服务停滞,也可见严重性。还是稳步试用比较好。

Re: 发现一个错字 by 典 刘

不客气,发现infoq上很少有人发言啊。infoq是很高端的网站了, 难道中国的精英都不喜欢交流?

Re: 发现一个错字 by David Fenng

允许匿名评论就好了。

除却4SQ 之外,Digg 运用 Cassandra 的经验也不是很成功。

看来需要预警措施 by 曹 云飞

比如在内存使用了50G的时候能够向系统管理员发报警短信

整理碎片应该是个常规事务 by Shichao Liu

做不到魔兽那样每周一次, 也该做到每月1次, 或者定期监测硬件使用率, 这次宕机完全可以避免.

MongoDB对于高负荷和超负荷的响应也有值得改进的地方, 接近临界的时候应该向管理员报警, 到悬崖边的时候应该拒绝新的事物, 并且把原因记在日志里.

期待新的在线压缩功能. 蚂蚁搬家似地勤奋压缩(很像垃圾回收呢)应该会取得很好的效果.

最好的办法就是..."等待" ??? by haoxiang zhang

最好的办法就是..."等待" ??? 等待吗? 如果没有这样的技术先锋,没有这样的案例, 怎么能得到经验, 怎么能成熟呢? 这种想法比较消极. 看到别人宕机就怕了吗, 不敢用了? 不敢去发现别的问题了,不敢去总结经验了吗?

Re: 最好的办法就是... by wang xuan

难道咱们要等到别人玩腻才跟上么?

与技术关系不大 by Junny Stone

技术在实际应用过程中并不占据主导地位,倒是凸显出计划性、适应性在业务过程中的决定性作用。试想,即使再好的技术方案,首先如果它不适合我的应用场景,如果再没有一个好的规划(至少在切换之初就该做好,对切换后任何意外的妥善处理方案),结果可想而知。

Re: 其实 by Han Meng

re~

Re: 发现一个错字 by 典 刘

您是twitter上的那位Fenng? 杨贵福的同学?

使用新技术需要更多的监控 by qd he

毕竟会出什么问题是未知的

過於熱衷! by David Fu

很多時候,我們追求新技術,而且瘋狂的擁護在無任何深切理解下。
比如最近幾個比較熱門的技術,很多人瘋狂認為nosql可以取代普通數據庫。實際上這兩種東西並不是競爭關係,而是互補關係。“右翼”份子總是發布文章告訴他人如何用nosql來取代mysql或者其他產品。
mongodb所用到mapreduce也經常誤解,特別是幾個入門文章(wiki上)。小弟認為,用mapreduce排序和組合的例子絕對是一種誤導

Re: 发现一个错字 by 霍 泰稳

InfoQ比较追求实名制,希望能给大家建立一个客观、真实的技术社区环境 :)

Re: 最好的办法就是... by yu yu

严重同意

最好的办法俨然不是等待

Re: 其实 by howard howard

同意你这个,shard算法没弄好的话,在那个数据库都有问题,只不过
因为 Shard 算法导致的数据分散不均衡,其中一台(Shard0)数据增长到 67GB(另外一台 50GB),超过了 66GB 的限制

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

19 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT