Tag Archives: flickr

再跟 Flickr 学习网站运维经验

学习了一下 Flickr 的运维工程师 John Allspaw 的这个Operational Efficiency Hacks 讲座内容。做一点笔记。

现在 Flickr 的数据相比2007年的时候真是有了显著的增长：

24 TB 的 MySQL 数据
每秒钟 MySQL 有 3.2 万次写操作
每秒钟 MySQL 有 12万次读操作
图片容量 6 PB
每天要用掉 10TB 存储
超过 15000 个服务监控点

在 2004 年的时候，Flickr 使用 ImageMagick (version 6.1.9)之后转移到 GraphicsMagick，我还以为是因为版权问题，现在知道这样做是因为速度，换用 GraphicsMagick 处理速度提升了 15%，而 ImageMagick 功能尽管强大，但都是 Flickr 用不到的功能。如无必要，勿增实体啊。GraphicsMagick 在并行方面(OpenMP)的支持也很不错(参考)。

除了技术手段的优化，Flickr 充分利用硬件本身的更新换代带来的好处，曾经用 18 台新机器替换掉原来的 67 台 Web 服务器，用 8 台新机器替换掉原来的 23 台图片处理的机器。无论从机架占用还是电力使用都节省了很多，而整理处理能力并没有削弱。我们总说摩尔定律，但是恐怕很少有人真的享受到摩尔定律带来的好处。Flickr 的做法是很值得学习的一个地方。精兵简政，不要只冲着人下手，动手”裁”掉机器，也会省钱嘛…

Flickr 技术团队随着网站的快速发展并没有增加大量人手，个人生产力的产出是相当的高。如何做到的呢？给出了四个非常有趣的原则：

使得机器自动构建 (Teach machines to build themselves)
使得机器自监控(Teach machines to watch themselves)
使得机器自修复(Teach machines to fix themselves)
通过流程减少 MTTR (Reduce MTTR by streamlining)

自动购建上，Flickr 使用了 OpsCode 、Puppet 以及 System Imager/Configurator 等。或许这几个工具值得我们关注一下。

Flickr 团队内部沟通工具也挺有意思，除了内部的 IRC 用于讨论之外，还利用 Yahoo! Messenger 的 IM Bot 记录更多的系统变化，并且，重要的是，将这些信息弄到搜索引擎里面 … “信息查找”，是国内多数团队交流工具忽视的地方。

最后感慨一下 Flickr 技术团队仍然是非常有活力的团队。最近的另一个消息是国内的 Yupoo.com 原创业团队也即将重装上阵，重新接管 Yupoo 网站，要知道 Flickr 仍然是最有影响力的网站之一，所以，有理由期待 Yupoo 团队的精彩。

–EOF–

《构建可扩展的 Web 站点》读后随感

对于构建 Web 站点，《构建可扩展的 Web 站点》重点并不是讲述 How-To 的 — 讲述 How-To 的书已经很多了，却很少有图书愿意分一部分篇幅讲述 Why 。所以有的人可能认为”缺少细节”，有的人则读罢大呼过瘾。我一般的建议是，如果你觉得这本书没劲，那就再读一下第二遍。

为什么我推荐这本书? 主要的原因是这本书给出了可扩展站点的必备要素，而书的内容几乎全是作者在 Flickr 站点实战中得来的经验谈，如果您的站点是个发展中的 Web 2.0 站点，你可以认为这本书是个技术”标本”。如果回顾一下我的 Blog 的话，会发现多则关于 Flickr 的技术话题：

当然，这些这些都是皮毛。

如果你正在为你的网站性能问题而苦恼，那么建议直接去读第八章，这一章也是让很多人觉得有价值的章节，因为讲的是”瓶颈”(可见如何解决网站性能瓶颈是个多么普遍的话题啊)。如果严格的来说，这一章的内容并非有多么深入，但对于需要对网站性能瓶颈建立全局概览的朋友来说，足够了。毕竟我们看书不是挑刺，解决自己的问题是首先要考虑的问题。

对我来说，第九章也让我收获良多。第四层负载均衡和第七层负载均衡的差别，什么时候合适用第四层均衡，什么时候用第七层均衡，如何构建一个第七层负载均衡网络… 这些看似都是基础的问题，但实践中是需要仔细平衡的一个事儿。并非想象的那么简单。

如果 Cal Henderson 能有下一部书的写作计划，我倒是希望能看到设计可扩展的 Web 2.0 站点的主题，当然，可能我们看不到了，因为，Flickr 被 Yahoo! 收购后似乎缺失了进取心，谁知道 Cal 会不会跳槽而走呢?

PS: 这也是我认为”Web 2.0 网站架构不可或缺的图书“清单中的一本。

–EOF–

从 Flickr 的 DB 服务器配置说起 Swap

又读了一遍这个 PPT： Federation at Flickr: Doing Billions of Queries Per Day ，发现还是值得咀嚼一下，尽管这”甘蔗”已经被吃过了。

针对主机环境的实践参考

Flickr 数据库的硬件配置一般用 16G 内存，6块 15K 硬盘，RAID 10，在 EM64T 下跑 RHEL 4，运行在 Deadline I/O 调度器模式。回写 Cache 用控制器电池而不用磁盘的 Cache。Swappiness 设置为 0 . 。

大内存数据库服务器的 Swap 设置问题

上面提到了 Flickr 是把 Swappiness 设置为 0 ，简单的通过:

echo 0 > /proc/sys/vm/swappiness

个别情况下这样也可能没起作用，因为实际上对 Swap 的调用是由如下的公式计算得到的：

swap_tendency = mapped_ratio/2 + distress + vm_swappiness;

其中 vm_swappiness 默认值是 60.

这是个防御性的措施。Linux Kernel 2.6 （个别版本）有些诡异行为，当有大量物理内存空闲的时候，Linux 仍(或许)会傻乎乎的调用 Swap 空间，这导致有的时候系统性能很差。有人建议如果是 INNODB 的引擎的话，可以用 O_DIRECT 的方式强制直接调用物理内存。但似乎副作用很大（存疑)。

如果关闭 Swap (swapoff -a)的话，又会遇到 OOM 的问题。这是绝对不推荐的。

还有人用的方式是把 Swap 建立到 RAM 盘上。

Swap 的自动校正其实是个老问题，几年前可能超过 4g 的 Linux 服务器都不多，而现在动辄几十 G 的内存配置，应用场景发生了很大变化，Kernel 的算法思路肯定也要调整一些了吧(尽管几年来不断看到有小的 Patch 出来，可好像 RHEL 的 Kernel 还是老样子)。

我在这里抛砖引玉，大家实际应用中应该也遇到类似问题吧? 有什么建议? 还是干脆就不管? 默认情况下其实也能跑…

–EOF–

侠客行恭候网络侠客

后天，第二届中国网络工程师侠客行大会就召开了。届时，会有来自 Google、微软、雅虎的顶级专家进行技术分享。

Web 2.0 元素

和上次预告除了与会嘉宾稍稍有点出入的是，Yahoo! 旗下的 Flickr 这次会派出 John Thrall 进行题为 Flickr Architecture 的技术演讲。MySQL AB 公司创始人与 CTO David Axmark 将在上午有 Keynote。另外，下午还有 David Recordon 带来的 OpenID 话题。应该说这次会议也充满了 Web 2.0 技术元素的(其实个人觉得开放平台/SaaS 才是重点)。

关于门票

准备参加的朋友如果没有在网络报名打印报名表，我这里还有几张空余门票。给我留言，注明下午参加那个场次。我会回邮件告知电话，到时候在会场找我即可。

大侠风尚、Single Party

下午听完讲座后，可以用门票换取晚上的大侠风尚和 Single Party 的门票。或许有朋友能结成良缘也说不定的:)

小广告: 支付宝招聘

支付宝技术部近期在招聘。网站上有相对具体的招聘要求，我们这边目前对架构师和 DBA 还是比较缺的。感兴趣的，联系我。

–EOF–