《Linux运维趋势》2012年5月号总第19期

编者的话
主编
杨赛

审阅
煮酒品茶《Linux运维趋势》眼看着就发布到了第19期，算
上一开始的测试刊和 Linux 20 周年时推出的特刊，到
现在已经走过了 21 期，22个月的时间。
出版方 “是时候做一些改变了。”
51CTO系统频道一方面，《趋势》最初以主题确立每期的内容方
（os.51cto.com）向，随着期数增多，却也限制了取材的范围；另一方
面，原本的版式学习自横版的《Full Circles》，虽然
在PC上更具观赏性，但在往专业的杂志平台推送、以
及转换成电子书格式的过程中，都遇到一些问题。
出版日期
这个时候，我阅读到一篇关于《Hacker Monthly》
每个月的第2个星期五
的文章，这令我对《趋势》未来的发展，有了新的想
法。

邮件订阅所以，就有了今天这个改头换面的《趋势》新刊。
如果你对此有什么想法，欢迎随时反馈！邮箱
http://os.51cto.com/ （yangsai@51cto.com）、微博／推特（@lazycai）
art/201011/233915.htm 或QQ（502965602）均可。 ■
——lazycai
RSS订阅（最早发布）
http://www.51cto.com/
php/rss.php?typeid=777

《Linux运维趋势》是由51CTO系统频道策划、针对
Linux/Unix系统运维人员制作的一份开放的电子杂志，
iPad订阅
内容从基础的技巧心得、实际操作案例到中、高端的运
《读览天下》客户端维技术趋势与理念等均有覆盖。我们的所有内容均收集
整理自国内外互联网，每篇文章都会严格标注出处与作
者，同时编辑也会尽力联系每一篇文章的原作者进行确
联系电话认。如果您认为本杂志的内容侵犯到了您的版权，可发
信至yangsai@51cto.com进行投诉。
010-68476606-8035

目录

本月推荐专题
05 百度云首席架构师林仕鼎：工程师应 22 警惕程序日志对性能的影响
如何突破瓶颈文／杨文博（solrex）
采访整理／杨赛
24 一次博客的性能故障排查
08 探秘Facebook的交付工程团队和BT 文／BOYPT
部署系统
文／ Ryan Paul 编译／核子可乐 26 三招解决MongoDB的磁盘IO问题
文／ nosqlfan
技术分享
28 MySQL数据库中order by的实现和
16 Django 托管在 Github 上的实践 by rand() 的优化
文／ Perchouli 文／丁奇

18 /dev/null 2>&1 详解观察思考
文／南非蚂蚁
30 阿里巴巴集团去IOE运动的思考与总
19 Shell脚本自动记录登陆后的IP地址结
和历史记录文／mysqlops
文／ Trespassers
33 挑战无处不在
20 批量下载Linux运维趋势引发的反思文／陈皓
文／煮酒品茶

04 本月推荐 Linux运维趋势 2012年5月号总第19期

本月推荐

百度云首席架构师
林仕鼎：工程师应
如何突破瓶颈
采访整理／杨赛

在今年的百度开发者大会上，百度云战略高对于架构师的成长之路，林仕鼎先生有什么
调发布，成为开发者们瞩目的焦点。一直以来在看法？近日，51CTO编辑对林仕鼎先生进行了一
公共领域很低调的百度移动·云事业部的首席架次采访，讨论这方面的话题。以下为采访实录：
构师，也在当天以百度云首席架构师的身份站到
了前台。在他的博客上，他喜欢谈谈架构，谈谈 51CTO：您最近的博客将架构分为三类：软件
安全，谈谈火车票订购系统，谈谈OS的内核架架构，系统架构，以及大规模分布式架构。能具
构；在他的微博上，除了讨论技术之外，也喜欢体讲讲一开始接触架构设计的时候是怎样的背景
晒晒团队，谈谈社会与生活。吗？
他是林仕鼎，一位自称“西二旗跨界架构林仕鼎：其实我对架构设计的看法主要还是
师”的资深技术男。他的成长历程是典型的研究源于项目经验，做过的事情多了，于是开始总结
学院派：和提炼。架构设计不是一个单独的行为。它在系
统设计和实现的过程中发生，或者在事后总结提
炼生成。我觉得并不存在一个单纯的、独立的“
架构设计”。

51CTO：您最初开始接触计算机和编程是什么
时候？为什么会喜欢上CPU设计和内核架构这个
领域的？
林仕鼎：我从95年到02年都在北航6系，真正
编程始于大二。大二上半年用C做了个跳棋小游
戏，暑假时帮一个老师干活，做了个基于单片机
的图形化控制系统。这个控制系统大概用了一两
万行的8051汇编代码，在此过程中我隐隐约约地
悟出了资源管理、函数调用和模块封装等理念。
虽然以今天的眼光来看，这些经验都很粗糙，但
奠定了我做底层系统的基础，也从此喜欢上了这
一领域。后来在本科阶段做的工作也主要与网络
通信和并行程序相关，在读研时因缘巧合加入了
实验室的OS小组。

投稿信箱：yangsai@51cto.com 05

“不同阶段工程师的瓶颈是不同的，有
些人需要多写点程序，而有些人却需要从
程序中跳出来。”

51CTO：当时学习OS Kernel主要是通过阅读
论文吗？在这种深层次的领域，有没有觉得有时
候特别难懂，好像自己的成长陷入一个瓶颈，特
别烦躁的情况？
林仕鼎：我当时主要通过阅读Linux kernel源
码和CPU (i386, SPARC) 手册来学OS kernel的。半
年多的时间，一些关键代码基本是一行一行研究
的。在那个阶段，总是有新的东西可学，觉得每
天都在进步，一直都很兴奋。我的看法是Linux
kernel（或者Unix-like kernel）的最关键之处在
于进程的创建、调度和切换，当时在把0号和1号
进程搞清楚之后，真的是手舞足蹈兴奋不已。有
几天觉得最复杂的程序都研究清楚了，也不过如
此，甚至产生了“身登绝顶我为峰”的幻象。不
过这个幻象很快就被打破了，因为有人问了我一
个问题，我哑口无言。这个问题是“Linux 简言之，通过写code和辛勤工作深刻理解
kernel有什么缺点？如果你自己设计，会怎么改 how，通过阅读和思考逐渐体会到why，二者需要
进？”后来，我开始阅读一些关于OS架构的论持续迭代不断升华。通常工作中得到的只是
文，这些论文为我打开了一扇进入系统领域的大 experience，思考后才会变成自己的skill；而阅
门。读中得到的一般也只是 information ，使用后加
在我身上，比较少有陷入瓶颈的情况，一般深理解才会变成 knowledge；把skill和knowledge
我都在不停地迎接新的挑战，这可能也跟我的经结合起来，才会真正形成自己的expertise。于
历有关。此，才有可能具备前瞻性，知道 what to do
next。
51CTO：对于突破瓶颈，您个人有什么经验分
享吗？有没有和导师、师兄弟们交流过这方面的 51CTO：后来接触分布式系统又是从什么时候
事情？开始的？您提到大规模分布式架构的重点是资源
整合、快速交付和运维问题，而系统架构的重点
林仕鼎：不同阶段工程师的瓶颈是不同的，是资源的分配与复用，这当中的异同具体表现在
有些人需要多写点程序，而有些人却需要从程序哪些方面？
中跳出来。对于需要从程序中跳出来的人，我的
百度空间里有篇文章，可供一读：《架构相关领林仕鼎：2002年毕业后，我加入微软研究院
域的学习材料》。的系统研究组，主要研究大规模分布式系统和高
性能系统架构。这段时间的主要工作是问题域研
另外对于架构师的成长，我也有张图，总结究、系统设计和原型实现，真正做出实际系统是
了我个人的经验：在我到百度工作之后。


“移动和物联网提供的是interaction
和connectivity，云计算提供的是处理
能力，而大数据产生智能。”

分布式架构和系统架构是两个维度的技术。 51CTO：之前看您提到过百度的绿色数据中心
从规模上来看，分布式架构通常关注的是机群或计划，这方面目前的进展如何？有没有计划跟其
IDC，而系统架构则是单机。从目标上来看，分他同行，比如淘宝的工程师团队进行合作？
布式架构主要保证availability，而系统架构提供
performance。在一个实际系统中，通常这两个林仕鼎：我们的绿色数据中心计划包括三个
维度的技术都会有所体现。方面：IDC、服务器和新硬件。

对于这几个类型的架构划分，都是纯粹的个 IDC方面，我们自行设计的M1数据中心已经运
人观点，不一定是成熟的或业界公认的。我的习营半年多了，除了常规的直流供电和新风制冷等
惯是，先把一些复杂的问题解耦、分离成独立的技术，我们还设计了冷热风道隔离和智能调节，
子课题，这样比较容易找到切入点和理解问题当前的成果是夏季平均PUE是1.4左右，冬季大约
域，然后再把不同维度的技术结合，针对具体问 1.1，这应该是国内的领先水平了。
题和环境做出不同的折中考虑，最后形成最终解服务器方面，我们正在设计整体机架式服务
决方案。器以及基于ARM的低功耗高密度服务器。新硬件
则包括自行设计的SSD、FPGA卡等。
51CTO：现在百度移动、云计算这块，您目前
主要关注的方向是什么？这些设计我们都会逐步开放，也很欢迎其他
同行采用我们的做法或共同研发。
林仕鼎：我当前的主要工作是把面向数据处
理的云计算平台、面向网络服务的应用引擎以及 51CTO：最后一个问题有关新人的培养。您现
面向网页的浏览器平台结合，形成一个更具有普在招聘工程师主要看中哪些方面？有没有什么可
适性意义的OS平台，供WebApp运行。以快速招到（或者定位到）合适的人的经验可以
现在有几个大的技术浪潮，移动、云计算、分享？
大数据以及物联网。在我看来，移动和物联网提林仕鼎：就我个人而言，我最看重的是工程
供的是interaction和connectivity，云计算提供师的抽象能力和对问题变化的敏感性。很多年
的是处理能力，而大数据产生智能。我们的工作来，对于新人我只用一道面试题，很简单的数据
就是整合这些能力，使其变得普适化，使App可结构建模，然后变化一些条件，看他的处理方
以更方便地使用。然后App做什么呢？我的看法案。
是用来 program web。Web 上有足够的 data 和
services，App可以更智能地把这些能力都串联起 51CTO：好的，问题到此结束。感谢林仕鼎先
来，更好满足用户需求，提供更自然的交互方生接受我们的采访！■
式。
这些技术与互联网的结合，将开启一个全新
的时代，我认为这就是继PC和互联网之后的云的
时代。这也是百度云战略的发展目标。
原文：http://os.51cto.com/art/201205/334675.htm


探秘Facebook的
交付工程团队和
BT部署系统
文／ Ryan Paul 编译／核子可乐

Facebook有一套成熟的软件交付流程，平均我前几天刚刚获准对Facebook总部进行专
30分钟可完成一次升级。这套流程的背后有一个访，全程跟踪这家社交巨头的交付流程工
交付工程团队，以及一套BT部署系统。这个系统作。Facebook公司正在筹备并部署一项全新社交
是如何运作的？Arstechnica网站去拜访了一次这功能，即“timeline”系统。而我则以独家观察
个交付工程团队，揭开了这个系统的神秘面者的身份参与到项目当中，随时收集第一手信息
纱—— 并将资料整理发布。
Facebook总部设立于加利福尼亚州门洛帕克在Facebook园区入口与前往企业办公地点通
市，这同一片园区在多年前孕育出了Sun 路的交汇处，一个交通指标牌映入我的眼帘，上
Microsystems这家同样声名在外的高科技企业。面写着：黑客之路。正如该公司创始人Mark
园区入口处矗立着巨大的宣传看板，相信每一位 Zuckerberg在今年早些时候的首次公开募股信中
用过Facebook的朋友都不会对上面竖起大拇指的所言，他希望能以“黑客之路”的方式规划企业
图案感到陌生——赞，这是用户表达肯定态度的管理理念以及发展方向。在Facebook总部逗留的
方式，可能也标志着Facebook公司对自身成就的两天当中，我第一次与他们的交付工程师们共同
评价。我最近一次到园区采访的时候，恰好碰上生活、携手工作，并真正了解到黑客之路这一概
一群十几岁的少年们聚集于此，争相在宣传板前念如何在该网站的成长与迅速普及当中起到决定
合影留念。性作用。
一部席卷全球的热门影片“社交网络”让成门洛帕克市的总部园区占地面积巨大，其间
千上万普通用户了解到Facebook公司如何从学生排布着密密麻麻的办公建筑；与其说是企业园
宿舍内的构想成长为世界第二大巨型网站，这样区，这里倒更像是一个小型城市。建筑物当中随
一个丑小鸭变天鹅的故事本身就极具传奇色彩。处可见精致的涂鸦式壁画及充满幽默气息的海报
然而恐怕很少有人知道这家社交网站成功的背装饰。与传统的封闭或半封闭式办公环境不
后，有多少技术人员在交付工作方面付出了艰辛同，Facebook公司的开发人员一般会在大片开放
的努力：先进的高科技基础设施造就了如今每天式空间中进行工作，办公设备也沿着公用桌面排
数以百万计用户的交互式Web应用体验，而这正布，员工之间没有设置任何阻碍视线的隔挡。
是无数工程师呕心沥血打造出的傲人成果。


Chuck Rossi，Facebook交付工程团队的领导者，正坐在Hotfix吧旁接受采访

每座办公建筑中都配备有公文室，在这里工这个房间原本在两根垂直支撑柱之间设有一
作人员们可以在不干扰其他同事的前提下尽情开面背景墙。但在交付工程团队入驻之后，他们将
展讨论。有趣的是，每座建筑中的会议室都会以这块区域改造成了酒吧吧台，并在台面上挑起他
特定的主题命名。比如某栋楼里的会议室就是们精心挑选的名称：Hotfix（热修复补丁）吧。
以“狂蟒之灾”这部电影中的一个笑话为名。另不用问，这个点子来自关键性软件补丁更新技
外，我还亲眼见到一些以电视节目命名的房间。术。而这里的员工就在围绕在吧台周围忙活手头
而在工作人员的陪同下进入另一栋建筑时，我发的工作。
现一间名为JavaScript：The Good Parts的房间。
哈哈，这肯定是来自Doug Crockford所撰写的同我正是在这里第一次见到交付工程团队的领
名著作。导者Chuck Rossi。Rossi的工作设备就在吧台对
面，这样他可以在工作的同时一伸手就抄起台面
最终我来到交付工程团队的办公所在地。正上的酒水饮料。我花了整个下午与这位曾效力于
如Facebook公司中的其它开发人员一样，交付工谷歌与IBM公司的资深软件开发人士谈天说地，
程师们同样使用开放式工作环境与公用办公桌。这段时光非常美妙，真的像两个老朋友坐在科技
不过他们的房间仍然具有非常鲜明的特色：这里气息浓郁的后现代酒吧中畅所欲言。正是以这种
实际是一个酒水品种相当丰富的酒吧。方式，我了解到Rossi如何带领他的团队帮助
Facebook部署更新服务，并讨论这项工作的重要
性及日常运作流程。


“频繁的更新及发布是Facebook在创立之初
就确定下来的核心发展理念之一。”

Facebook的BT部署系统当然，二进制可执行文件只是Facebook应用
程序堆栈中的组成部分之一。Facebook页面中还
Facebook资源代码主要利用PHP编程语言进行包含诸多调用自外部资源的项目，例如
编写。PHP语言在开发速度方面优势明显，但在 JavaScript、CSS以及图形要素等。这些文件被托
性能方面比起低层次语言及某些现代编程替代方管在分布于世界各地的内容交付网络（CDN）当
案却颇有不足。为了让这套以PHP为基础的基础中。
设施在可扩展性领域更进一步，Facebook开发出
了一套名为HipHop的特殊转译工具。一般来说，Facebook会在每个工作日进行一
次非关键性更新。而重大更新则每周进行一次，
HipHop能够将PHP代码转译为高度优化过的通常在周二下午进行内容发布。交付工程团队专
C++代码，并通过二次编译将其转化为运行效率门负责管理此类更新的具体部署工作，并全程跟
极高的本地二进制代码。Facebook于2010年正式踪以确保更新的顺利完成。
推出HipHop并开始销售开源软件使用许可，同时
该公司的工程师们指出，在HipHop的帮助频繁的更新及发布是Facebook在创立之初就
下，Facebook业务流程中的CPU平均使用率瞬间确定下来的核心发展理念之一。在该公司刚刚迈
降低了50%。入起步阶段的时候，开发人员利用快速迭代及增
量工程手段坚持不懈地对网站加以完善。这种技
由于Facebook所使用的整套代码库都通过编术层面上的灵活性在Facebook的发展及演变当中
译转化二进制可执行文件，因此该公司的整个部起到了关键性作用，并成功让这家年轻的企业迅
署流程与我们耳熟能详的PHP环境颇为不速成长为举世瞩目的社交巨子。
同。Rossi告诉我，Facebook所有应用程序的二进
制代码库总体积约为1.5GB。当Facebook对代码当初Facebook公司招募Rossi的时候，是希望
进行升级并生成新的软件包时，新的全局代码库他能够领导交付工程团队找到合适的途径，确保
也必须同时被推送到企业内部的每一台服务器当企业在快速发展的同时步伐稳健、基础牢固。对
中。于正处于急速扩张当中的Facebook而言，其网站
的规模与管理复杂性也在以几何级数式增长。要
把1.5GB大小的二进制代码分配给不计其数的实现牢固稳妥的交付战略，传统的解决方案已经
目标服务器，工作当中面临的技术挑战想想都令无法满足需求。正是在这时，他们想到了BT部署
人头痛。在摸索出几套成型的解决方案之系统。
后，Facebook公司决定将BT技术敲定为最终手
段。这种人气极高的点对点文件共享协议在向大在与Rossi共同度过的那个愉快的下午，我在
量不同服务器传输大型文件方面拥有着不可替代概念上基本理解了他解决Facebook部署问题的处
的优势及上佳表现。理方式。总结起来，他希望能在客观条件与理论
目标之间找到一个平衡点。他制定了一套相当严
Rossi解释称，Facebook公司创建了自己的定格的质量及稳定性标准要求，但具体到解决方案
制BT追踪工具，其设计目的是使Facebook基础设层面却将着眼点放在高灵活性上。资源总是有限
施中的每一台服务器都能够与同一节点或机架中的，他认为最好的办法是通过系统灵活性来应对
的其它服务器一样获得相同的分区内容，如此一各种意想不到的麻烦。
来总体延迟将得到大大降低。
目前Facebook网站升级的平均耗时为30分
钟——其中15分钟用于生成二进制可执行文件，
而另外15分钟则花费在通过BT体系将可执行文件
传输至各Facebook服务器的过程中。


“在Facebook公司内部存在着这样一种
优秀的开发文化，大家都认为开发人员
应该为自己编写的代码负责到底。”

测试工作预检流程
在最近的几篇文章中，我们已经与读者朋友 Facebook利用自己的内部多人在线聊天系统
深入探讨了软件应用程序步入高速交付周期所带（IRC）服务器保持企业中的交流通畅。大多数
来的挑战与机遇。而挑战当中最难以克服的一个企业的工程人员在工作强度较大时，交流通道都
就是，如何在测试时间远低于原先水平的前提下显得比较冷清。但根据Rossi的说法，Facebook公
保证软件的质量不打折扣。司在正常运作状态下，每天会有约700名员工保
持在线沟通。工具开发人员专门为IRC打造了几
由于Facebook网站每天都会进行更新，因此种业务助手软件，能够将IRC中的各类功能与
质量测试也就成了压力最大、负荷最强的先锋部 Facebook开发与部署工作流程紧密结合，进而发
门。为了快速发现问题，Facebook中每一位通过挥巨大的辅助作用。
企业内部网络访问该社交网站的员工，都将直接
登入采用了最新代码的实验性网站架构。在这里在新一轮升级补丁即将上线之前，Rossi会在
他们能够接触到一切尚未经过测试的修改建议以 IRC系统中启动一套检测程序。在此次更新活动
及还没有在正式网站上采用的最新功能。与此同中提交过代码的开发人员都将收到通知，并加入
时，员工还可以通过另一个单独的网址访问与外频道以共同关注更新过程。整从此更新流程将在
界用户相同的正式运行版网站，这样两相对比之大家的协同监控之下试作一次，当确认一切正常
下可能更容易发现问题。后才会进入实际部署阶段。
将测试网站设定为企业员工的默认访问对如果某位开发人员在几分钟之后仍然没有做
象，能够在新元素及功能付诸实践之前先经受专出协作回应，Rossi能够利用助手通过多种不同的
业人士的检测。测试网站中还包含了一些内置的通讯渠道对该开发人员发出提醒，其中包括电子
错误报告工具，员工一旦发现问题，就可以利用邮件通知以及短信提示。正如Rossi在与我的交谈
它们轻松提供详细反馈。中所强调的，他希望部署更新的时候所有与之相
关的开发人员都能在场监督并发表意见。
为了避免回档事故并确定通用性技术问
题，Facebook还部署了一套自动测试系统。该公在Facebook公司内部存在着这样一种优秀的
司将这类测试分为两个独立的部分：一部分专门开发文化，大家都认为开发人员应该为自己编写
进行代码的常规完整性测试，而另一部分则模拟的代码负责到底，直到这些成果顺利应用于产品
用户的日常使用情境，以确保网站的用户界面能之中。这一理念的实际体现就是“DevOps”活
够运转良好。动，这种促进开发、技术运营及质量保障部门间
沟通的方案有效消除了各团队之间的沟通障碍，
在更新全面付诸实践之前，新的代码将首先并最终保证了项目的成功运转。
被推送到“a2”层，也就是由数台Facebook公共
服务器组成的试点环境。在这个阶段的测试工作如果Facebook网站在实际更新过程中出现问
中，会有一些随机Facebook参与到更新中来。尽题，编写相关代码的开发人员会立即得到提示，
管参与者的数量在Facebook全局用户群体中只占并马上投入到修复工作中去。
极小的比例，但技术人员仍然能从整个更新流程
中发现潜在问题并及时加以修复。


实际部署事后检查
Rossi在Facebook公司中的工作台由以下设备更新流程彻底结束之后，Rossi还需要做进一
构成：一台30英寸戴尔显示器、一台Mac笔记本步审查，以确保系统变更没有对任何层面的原有
电脑以及一台分屏显示器。上周二，我花了一整内容造成破坏。他的团队为此专门打造了一套先
天时间观察Rossi的日常工作内容，发现他的大部进的分析工具，其作用是追踪Facebook网站的各
分工作都是在浏览器以及终端窗口中完成的。在项运行状态。工具的主仪表板上的线形图显示出
准备部署更新之前，他在终端窗口发出指令，正各检测指标的变化情况，包括流量、资源消耗、
式启动本次升级流程。产品独立组件故障率以及其它各种重要数据。
我们一同关注着Facebook网络系统监控工具关注这些系统状态的浮动与走势，能够有效
所显示出的各项状态指标。网页的主体内容是个帮助工程人员辨别并修正系统中出现的问题。在
大大的进度条，标明企业内部已经成功完成二进故障发生之初，技术人员能够快速将当前数据与
制文件更新的服务器所占的百分比。随着更新的历史记录进行比照，并轻松准确地查明问题出在
自动部署，进度条也在不断向终点推进。过程哪里。交付工程团队及其它Facebook工程小组会
中，进度条左端出现了窄窄的红色提示条，意味在更新结束后继续严密留意网站的运行状态，以
着新版本在更新时发生错误的系统比例。确保一切项目及功能仍然运转良好。
Rossi告诉我，这种系统更新失败的情况经常一旦发现问题，例如系统中的某部分出现不
发生。在部署过程中，升级失败往往是由硬件问合理的高故障率，那么企业中的工程师们将立即
题所引发。举例来说，如果某台服务器的存储容开始对错误日志进行深入分析，以找出问题发生
易不足或者运行种子文件时遭遇网络问题，那么的根源。Facebook所使用的内部工具非常犀利，
更新很可能无法完成。不过出错的服务器数量一在它的帮助下技术人员可以很轻松地观察并分析
般都很小，只需简单调整即可恢复正常，几乎不日志内容，并将结论与代码变更及特定错误提示
会惹出什么大麻烦。相结合，最终拿出一套最为简洁高效的修复方
案。
尽管软件的部署对象是服务器，但Rossi告诉
我Facebook的架构仍然会对更新过程产生一些独 Facebook所使用的内部监控工具能够追踪大
特的影响。Facebook在设计之初要求用户会话能量数据源，甚至连与Facebook相关的tweet消息
够不依赖于任何特定的服务器设备，以分布式程也涵盖在内。通过收集与汇总，该工具将分析结
度极高的无地区差形式进行运作。也就是果以单独的走势曲线图进行表示，直观展现了网
说，Facebook基础设施中的任意一台服务器都能络用户对Facebook正面与负面评价的所占比例及
够处理任何给定的页面操作请求。变化。这一点非常重要，因为当我们在某种社交
网络中遭遇技术缺陷或应用故障后，很可能会在
这种方式为全局系统提供了异乎寻常的弹其它网站上大肆抱怨以发泄怒气。对这类内容保
性。当Facebook执行更新时，工作人员不必担心持关注，就能帮助Facebook的技术人员迅速掌握
用户会话的状态会受到干扰或进行迁移。部署系那些可能被自己忽略掉的系统故障。
统会在服务器端分批对Facebook执行流程加以重
启，这样一来整个更新过程就能够以无缝化形式根据我的观察，当天的更新流程非常顺畅，
进行。无论是已经完成更新的还是仍然运行着旧没有出现任何技术问题或系统故障。日志消息的
版本系统的服务器，都能够继续处理接收到的用图表中曾经显示某个系统组件出现了小小的负载
户页面请求，而与此同时企业基础设施的全面更高峰，但通过Rossi及其团队的及时追踪及排查
新也在有条不紊地进行当中。后，发现一切都属于正常现象。
Facebook在更新与正常业务同时运转的情况
下，系统设施将几乎处于满负荷状态。通常情况
下，Facebook典型更新在部署中不需要预设停机
时间，也绝不会引发任何形式的网站服务中断现
象。Rossi指出，无停机更新流程是Facebook交付
工作策略中的一项原则性要求。他为此感到自
豪，并认为这是对网络软件工程工作优秀与否的
一种检验。


Facebook公司交付工程团队在庆祝“一周一度”的更新成功

回档是失败者的行为他告诉我，对于Facebook这样的大型社交网
站而言，进行系统回档就像拉下火车上的紧急刹
尽管在我的采访过程中并没有出现什么乱车一样；这么做并不可取，因此除非别无选择，
子，但Rossi还是非常热心地满足了我的好奇心。否则他们绝对不会尝试。在他就职于Facebook的
这个问题其实也一直在困扰着我：一旦更新过程数年中，系统回档的情况也只碰上过几次。
发生故障，Facebook会怎样处理？他的回答是，
如果在更新结束后有一大堆错误暴露出来，交付 Facebook的测试机制以及开发人员问责理念
工程团队将与相关开发人员通力合作，力争在最有效防止了代码编写工作中出现严重错误的机
短的时间内解决这一问题。当修复方案准备就率。当开发人员的代码破坏了网站架构时，他们
绪，Rossi的团队将立即将其投付部署，并组织新不仅需要立即投入修复工作，还必须承担绩效评
一轮更新。估及人事变动等层面的惩罚。Facebook公司中的
代码归属与开发人员紧密相联，因此根本不用指
当某些错误太过严重时，快速修复几乎是不望在捅出娄子之后仍然高枕无忧。
可能完成的任务。因此我问他此前有没有将网站
恢复到旧有版本的经历。但他的回应斩钉截该公司所使用的内部工具具备一种标志性的
铁：“回档是失败者的行为！“ Facebook式灵感，而Rossi也对这种评估机制赞不
绝口。这是一种评分工具，它赋予了Facebook公
不过他又微笑着补充道，事实上他确实也执司中每位员工一定的“karma”值，这一佛教用
行过系统回档。Facebook拥有一套合理的机制，语通俗一点来说可以看作是“善恶值”。善恶值
能够快速高效地将系统恢复到上一个版本，但他与代码审查系统直接挂钩，每位开发人员在网页
们只将此作为最后一项保障性手段使用。每台服仪表板中都拥有自己的状态栏，Rossi可以通过点
务器中都保存着上一个版本的二进制文件，并能击栏中的“顶”或“踩”图标来提升或降低对应
够在绝对必要的情况下立刻进行切换。员工的善恶值属性。


Facebook公司交付工程部门中的Hotfix吧——以酒补过，原来这才是hotfix的真正含义

在Rossi的工具中，表示“顶”的功能图标与
Facebook社交网站中的那个完全一致。而表示“
踩”的图标则正好是把“顶”的图形上下倒
置。Rossi不无得意地向我展示了他的图标，并开
玩笑说他是世界上惟一一个能使用Facebook式“
踩”图标的家伙。
善恶值的设定能够帮助Facebook公司时刻掌 “每台服务器中都
握员工的工作状态，不过在代码审查过程中，评
分机制同样能够帮上大忙。在对更新代码进行整保存着上一个版本的
体整合时，Rossi能够一目了然地发现哪些代码是
由“善恶值”较低的技术人员所编写，这样他就二进制文件，并能够
会对这些代码格外关注，因为这帮家伙出错的潜
在风险更高。在绝对必要的情况下
善恶值较低的员工可以通过自身的良好表现
及工作态度逐渐提升这项评分——不过也有些人
立刻进行切换。”
冥顽不灵，他们居然打算通过给Rossi带小点心的
方式让他放自己一马。不过最令人惊讶的
是，Rossi真的认同了这一做法。他告诉我，酒和
蛋糕是员工恢复善恶值的首选礼品。说到这里，
他又指了指交付工程团队办公室中那令人印象深
刻的酒水储备：其中很大一部分就来自犯了错的
开发人员。


“Facebook的开发人员正在创建自己独
有的字节码格式及自定义运行环境，他
们将其称为HipHop虚拟机，并希望它能
成为支持Facebook运行的下一代平
台。”

发展前景一旦上述理想能够成为现实，整个大规模更
新流程将能够在数分钟内完成，而Facebook也就
我与Rossi探讨了他对于发展前景，尤其是可以借此彻底抛弃以往的更新时间表，真正按照
Facebook的部署策略在企业技术基础设施发生变开发思路将增量部署纳入变更模式之中。在这种
化之后的预期走势。他认为，随着时间的推移，情况下，企业开发人员则获得史无前例的高度敏
他的团队在工作效率方面将进一步提高：准备过捷性。
程、构建工作以及部署耗时等项目都还有潜力可
挖，到时候整套更新任务可能几分钟就能搞定。在周二例行的关键性更新结束之后，Rossi和
他的团队开始对系统加以分析，以确保更新工作
目前Facebook最重视的开发工作之一是推出没有引发任何问题。当一切圆满结束之后，他们
一个能够取代HipHop转译器的新型后备项在hotfix吧举杯畅饮以示庆祝。
目。Facebook的开发人员正在创建自己独有的字
节码格式及自定义运行环境，他们将其称为欢乐的时光总是过得特别快，在结束了一天
HipHop虚拟机，并希望它能成为支持Facebook运的采访、再次漫步在Facebook园区的黑客之路上
行的下一代平台。这一项目完成之后，该企业将时，我不仅慨叹默默无闻的“交付工程团队”在
能够把PHP源代码编译成能够为虚拟机直接运行扶持Facebook顺利发展的道路上起到了如此巨大
的字节码。的作用。
如此一来，托管代码模式将更接近于Java及. Facebook尽心竭力所打造出的社交平台，让
NET，这样的进展能够让Facebook在保证代码一我们每一位普通使用者得以在其中分享过往阅
致性的前提下进一步提高系统灵活性。抛开其它历、记录当年点滴，这不禁令人心生景仰。而在
各类优势不谈，Rossi告诉我这种态势将对现有部这喧闹繁华的平台背后，却有着这样一群从未出
署流程产生重大影响。过去每一次更新都必须在现在灯光下的技术人员。他们拥有强大的知识背
所有服务器上传输1.5GB体积的二进制代码库，景，创造着与大多数人不一样的奋斗故事。希望
而未来他们只将与修改内容相关的字节码发出即大家记得，正是由于这些个性鲜明、可敬可爱的
可完成更新。Facebook网站甚至有能力将更新字人们的存在，Facebook才能始终光辉耀眼、独领
节码与正处于运行状态的应用程序直接拼接，这风骚。 ■
样连进程都不必重新启动了。

原文：http://arstechnica.com/business/news/2012/04/exclusive-a-behind-the-scenes-look-at-facebook-release-engineering.ars/
译文：http://os.51cto.com/art/201204/328615.htm


技术分享

Django 托管在 Github
上的实践
文／ Perchouli

Django1.4上个月发布了，有些模块换了名 git的分支功能很强大，所以也很容易导致混
字，加密方式也变了，最明显的变动是目录的组乱。在github能看到的中心版本库origin，默认
织方式，manager.py和其他配置文件分开存放。能看到主分支master。其他分支被收在下拉列表
这些改动导致之前的目录组织方案将不再适用。里。
所以整理一下1.3之前在Github上的实践，今后
开发的新项目再转到1.4。通用的原则是：branch用来区分feature，tag
用来区分版本。所以如果每个开发者在github和
requirements.txt, local_settings.py 本地都建一个以自己的名字命名的branch，就违
背了这个原则，而且开发者超过5个branch列表
把Django项目托管到Github上，README是给就会变得很难看，merge也麻烦大。
不熟悉项目的人看的，未必得能给自己省多少力
气。但写requirements.txt绝对是双赢。Django 目前尝试较好的方案是：Github上是两个
项目肯定会用到一些模块(至少得装Django…)， branch——master和dev，开发者统一使用dev分
用一个txt文件列出所有会用到的模块，以换行支进行开发，代码也都提交到dev分支。需要部
分割：署的时候把代码merge到master，用master分支
进行部署。本地至少是master和dev两个分支。
Django==1.3.1 我就是一直在dev分支上开发，出现严重错误直
django-notification 接reset -hard把之前写的代码全部删掉。也有
PIL 代码写得很谨慎的，会新开一个分支，完成之后
simplejson 再merge。在本地要怎么建分支主要看个人习
在部署的时候，直接使用惯，没必要死规定。

pip -r install requirements.txt Deploy
就可以把需要的模块都安装上了。既然代码托管在Github上，最简单的方式自
local_settings.py主要是两种用途，一是用来然是在服务器上git clone一份readonly的代码，
存储一些个人设置，比如开发环境和生产环境中然后将其部署。实际项目中表现最好的是Nginx
不同的static文件夹设置；二是存放一些不适合 + uwsgi的配置方式，百万级PV仍然表现良好，
公开放在github上的信息，比如数据库密码。编相应的配置方法网上都有。如果是一个每天pv不
辑settings.py，加入下面这段代码到文件底部，超过4000的网站——更大的我没测试过，有相关
在加载settings.py时会检查是否存在local_ 数据欢迎补充——用测试服务器跑就可以
settings.py，如果存在则载入：了，nginx配置文件如下页所示。
try:
execfile(os.path.join(PROJECT_ROOT, ‘local_settings.py’))
except IOError:
pass
Branch

16 技术分享 Linux运维趋势 2012年5月号总第19期

如果要换成uwsgi的时候， server {
把proxy_pass改成uwsgi_pass就 listen 80;
可以了，测试服务器功能很 server_name .dmyz.org;
弱，不能多线程，控制超时， access_log off;
所以尽快更换过来比较好。 location / {
proxy_pass http://127.0.0.1:8010/;
Update proxy_buffer_size 8k;
client_max_body_size 25m;
现在服务器上是master分 proxy_send_timeout 90;
支，本地是用来开发的dev分 proxy_read_timeout 90;
支，和默认的master分支，在 proxy_buffers 8 32k;
dev上开发，代码更新到github proxy_busy_buffers_size 64k;
上，确认没有问题，merge并提 proxy_temp_file_write_size 64k;
交到master分支。这时候最好 proxy_headers_hash_bucket_size 128;
是服务器能自动知道master分 proxy_headers_hash_max_size 512;
支有更新了，自动pull代 proxy_set_header X-Real-IP $remote_addr;
码。github提供了很方便的接 }
口用来调用数据，以下是可运 }
行的例子，在服务器上用cron
运行或者是django-celery来跑
都可以： #通过github的api获得当前github上最新的
sha
# -*- coding: utf-8 -*-
response = urllib2.urlopen(‘https://
import urllib2 api.github.com/repos/github_user/
import json github_repo/commits’).read()
import subprocess
json_data = json.loads(response)
#通过git log命令获得最新的sha
remote_sha = json_data[0][‘sha’]
run1 = subprocess.Popen([‘git’, ‘log’,
‘-1’], stdout=subprocess.PIPE) #如果不相等，用git pull命令更新代码

run2 = subprocess.Popen([“grep”, if not local_sha == remote_sha:
“commit”], stdin=run1.stdout, stdout = subprocess.Popen([‘git’, ‘pull’])
subprocess.PIPE) else:
print ‘Already the latest’
commit, error = run2.communicate() Reload
local_sha = str(commit).rstrip(‘n’). 说了代码更新，顺带说一下重新加载代码的
split(‘ ‘)[-1] 问题。如果是直接用Django的测试服务器，会自
动重启；如果是用uwsgi，需要进行额外的设
置，但这和Github没太大关系，就不列在这篇文
章里了。 ■

原文： http://dmyz.org/archives/381


/dev/null 2>&1 详解
文／南非蚂蚁

shell中可能经常能看到：>/dev/null 2>&1 说清楚了吗，大家理解下吧！
命令的结果可以通过%>的形式来定义输出顺便对比述说下这么用的好处！
分解这个组合：“>/dev/null 2>&1” 为五部最常用的方式有：
分。
command > file 2>file 与command > file
1：> 代表重定向到哪里，例如：echo 2>&1
“123” > /home/123.txt
它们有什么不同的地方吗？
2：/dev/null 代表空设备文件
首先command > file 2>file 的意思是将命令
3：2> 表示stderr标准错误所产生的标准输出信息，和错误的输出信息送到
file 中。command > file 2>file 这样的写
4：& 表示等同于的意思，2>&1，表示2的输法,stdout和stderr都直接送到file中, file会被打
出重定向等同于1 开两次,这样stdout和stderr会互相覆盖,这样写相
5：1 表示stdout标准输出，系统默认值是1 当使用了FD1和FD2两个同时去抢占file 的管道。
，所以”>/dev/null”等同于 “1>/dev/null” 而command >file 2>&1 这条命令就将stdout
因此，>/dev/null 2>&1也可以写成“1> /dev/ 直接送向file，stderr 继承了FD1管道后，再被
null 2> &1” 送往file。此时，file 只被打开了一次,也只使用
了一个管道FD1，它包括了stdout和stderr的内
那么本文标题的语句执行过程为：容。
1>/dev/null ：首先表示标准输出重定向到空从IO效率上，前一条命令的效率要比后面一
设备文件，也就是不输出任何信息到终端，说白条的命令效率要低，所以在编写shell脚本的时
了就是不显示任何信息。候，较多的时候我们会command > file 2>&1 这
2>&1 ：接着，标准错误输出重定向到标准样的写法。 ■
输出，因为之前标准输出已经重定向到了空设备
文件，所以标准错误输出也重定向到空设备文
件。

原文： http://www.ixdba.net/a/os/linux/2010/0422/35.html


Shell脚本自动记录登陆后
的IP地址和历史记录
文／ Trespassers

今天一台线上的服务器不知道本来记录登陆后的IP地址和某 export HISTSIZE=4096
被哪个活宝执行了chmod -R 700 / 用户名所操作的历史记录 DT=`date ‘+%Y:%m:%d %r’`
home，造成了文件权限不对，密钥 export HISTFILE=”/tmp/
PS1=”`whoami`@`hostname`:
认证就读不到密钥了，所有人账户 ruige/${LOGNAME}/${USER_IP}
”’[$PWD]’
都登陆不上服务器了。排查了一下 ruige.$DT”
原因，排除了安全问题。那剩下的 (Linux系统提示符是用系统 chmod 600 /tmp
就是同事的误操作了。但是！变量PS1来定义的) ruige/${LOGNAME}/*ruige*
chmod -R 执行这个可是很让人怀 2>/dev/null
疑的！于是报着试一试的心态去 history
last，然后history。其实这时候通 USER_IP=`who -u am i 2>/ 以上脚本会在系统的/tmp新建
过查看历史记录查是没有什么意义 dev/null| awk ‘{print 个ruige目录，在目录中记录了所
了，人执行了命令之后肯定 $NF}’|sed -e ‘s/ 有的登陆过系统的用户和IP地址，
history -c 了。果然，全部查完 [()]//g’` 还有历史命令。我们还可以用这个
了，依然不知道没有查出来是谁，方法来监测系统的安全性。
(who -u am i 会显示系统中
有几个人历史命令就几条，这种也登陆进来的用户及登陆从哪个注意：最好再给ruige这个目录
没法问，问也白问。 IP登陆进来的，这里后面过滤加个t位：
算了，这次反正没有丢什么重了就取值一个登陆进来的IP)
chmod o+t ruige
要的数据，服务器也没什么事情。 if [ “$USER_IP” = “” ]
饶恕了这个大神吧。但是，万一下 then 补充：who am i和whoami的区别
次又有人误操作了怎么办，有一天 USER_IP=`hostname`
因为某人误操作了删除了重要的数 fi login:root
据怎么办.. if [ ! -d /tmp/ruige ] Password:
then $who am i
现在从两个方面入手，第一服 root pts/0 2007-08-16 13:16
务器安装第三方记录工具，可以记 mkdir /tmp/ruige
chmod 777 /tmp/ruige (:0.0)
录登陆的每个用户操作的日志，第 $whoami
二结合行政手段，最好有相关的规 fi
if [ ! -d /tmp/ root
章制度，如果你是运维部的老大，
可以定下。有奖有法。起到一个警 ruige/${LOGNAME} ] su tongrui
示的作用。 then #who am i
mkdir /tmp/ root pts/0 007-08-16 13:16
查阅了下相关资料，还是下面 ruige/${LOGNAME} (:0.0)
这个方法好： chmod 300 /tmp/ #whoami
在/etc/profile中写一个shell脚 ruige/${LOGNAME} tongrui ■
fi
原文：http://ruilinux.blog.51cto.com/4265949/845405 。有删节。


批量下载Linux运维趋势
引发的反思
文／煮酒品茶

无事闲逛的时候突然发现51CTO Linux运维趋把年份给去掉
势下载地址如下：
#awk -F” ,” ‘{ print $2 $3 }’ ~/test/
http://os.51cto.com/down/ cc1.html>cc2.html
linuxops/51CTO_linuxops_issue1.pdf
[root@localhost test]# cat cc2.html
一想，构造了个
《趋势》12期主题:服务器故障排除
http://os.51cto.com/down/
linuxops/51CTO_linuxops_issue2.pdf 《趋势》特刊主题:Linux开发
#这个删掉。
可以下载，于是就有此脚本的前提。
《趋势》第11期主题:iptables原理与常见应
思路：循环后用wget批量下载。用场景
#vim 51ctodown 《趋势》第10期主题：日志分析技巧分享

for((i=1;i<30;i++)) 《趋势》第9期主题：Puppet
do 《趋势》第8期主题：双机
wget http://os.51cto.com/down/
linuxops/51CTO_linuxops_issue$i.pdf 《趋势》第7期主题：网站迁移
done 《趋势》第6期主题：备份
#chmod +x 51ctodown 《趋势》第5期主题：内网开发环境
#./51ctodown
《趋势》第4期主题：性能瓶颈
不过，下载后发现文件名并不是我们想要
《趋势》第3期主题：运维与开发
的，故需要动手操作一下。
《趋势》第2期主题：可用性
思路：文件名呈51CTO*.1.pdf 51CTO*.2.pdf
...方式，这个规律可找。那么我们要改完后的文《趋势》第1期主题：监控与报警
件名如何来找呢？首先想到的是去官方找找有没
有Linux运维趋势的目录，那样就非常简单了。《趋势》第0期主题：运维自动化 #
这个删掉。
访问 http://os.51cto.com/art/201011/233915.
htm 把发布通告给copy到一个文件中。命名为把顺序给弄反过来，更符合我们的需求。
cc.html # tac cc2.html >cc3.html
以主题来查找标题并导出为cc1.html
#cat cc.html |grep 主题>cc1.html


“在有问题的时候百度，以及
找前辈们指导才是王道。”

# vim mvname Wget时就重命名：
#!/bin/bash for((i=1;i<30;i++))
do
for((i=1;i<=13;i++)) wget http://os.51cto.com/down/
do linuxops/51CTO_linuxops_issue$i.pdf
mv 51CTO_linuxops_issue$i.pdf `sed -n
mv 51CTO_linuxops_issue$i.pdf `sed -n “$i”p cc3.html`.pdf
“$i”p cc3.html`.pdf done
done 看张效果图吧：

[root@bogon cwtea]# chmod +x mvname
[root@bogon cwtea]# ./mvname
最终结果：（略）
在写重命名规则的时候，一直找问题。mv
51CTO_linuxops_issue$i.pdf `sed -n “$i”p
cc3.html`.pdf 这一段弄的我想死的心都有，sed
后变量好像是固定的。-n ‘$ip’ -n “$ip”
-n ‘$i’p 都不行，一直以为脚本出错，循环
出错，最后一一排查，得出sed -n “$i”p
filename 才完成，原来是sed后变量出错。所以
在有问题的时候百度，以及找前辈们指导才是王
道。
后来，dn833提供了一个建议：
“其实你wget的时候就能指定输出名的。”
dn833的建议非常好啊，越前越好，脚本能简本文只提供思路，实际操作过程很简单，高
就简。不过得先把目录给定义好才能够下载。适手勿笑。 ■
于自动化吧。
参考链接:(老男孩)http://oldboy.blog.51cto.
com/2561410/711342/

原文：http://cwtea.blog.51cto.com/4500217/845004 。内容有删减与修改。


专题

警惕程序日志
对性能的影响
文／杨文博（solrex）

做后台系统比做客户端软件的辛苦的地方，
就是不能让程序轻易地挂掉。因为在生产环境中
无法容易地复现或调试 bug，很多时候需要程序
日志提供足够的信息，所以一个后台系统的程序
员必须要明白该如何打日志（logging）。
很多语言都有自己现成的 logging 库，比如
Python 标准库中的 logging 模块，Apache 的
log4cxx(C++), log4j(Java)。如果你愿意找，很容
易能找到基本满足自己需求的日志程序库。当
然，自己实现一个也不是很困难。难点不在于写
这些库，而是如何去使用它们。
大部分情况下，我们关注的都是日志的级别
和内容。即哪些情况下，该打哪个级别的日志，
日志语句中，该怎么写。


“在一条日志中，信息量最大的是变量，
是函数返回值/字符串内容/错误码，因而变
量应该尽量放在靠前的位置。”

在程序开发的过程中，我们需要很多的日志乍一看，由于 log_trace 级别不高，在生产
协助分析程序问题；但在生产环境中，我们没有环境中肯定会关闭，那么这样做看起来对性能没
那么多的空间存储丰富的日志，而且日志量太大太大影响。但实际上 log_trace 可能是这样实现
对于问题排查反而是累赘。有些人使用预处理解的：
决这个问题，在 debug 版本和 release 版本中编
译进不同的日志语句。这样能够解决一些问题， #define log_trace(fmt, arg...)
但却使得在生产环境中无法轻易地打印更多的日 xx_log(LVL_TRACE, “[%s:%d
志。大部分人更接受的做法是，使用配置（参 [time:%uus]” fmt, __FILE__, __LINE__,
数）控制日志的打印级别，在需要更多日志的时 log_getussecond(), ## arg)
候，可以随时打开它们。为了实现日志“少但是 #endif
足够”的目标，开发人员必须明白日志信息的价可以看到 log_trace 宏中自动添加了很多信
值，即哪些日志应该属于哪个级别。息，值得注意的是时间参数 log_getussecond()
日志的作用是提供信息，但不同的日志语。大家都知道统计时间需要系统调用，那么无论
句，提供的信息量却是不一样的。有的日志里会 log_getussecond() 函数是如何实现的，它的代
写“Failed to get sth..”，但却忘记加上失败调价肯定是高于一般的简单函数。
用的返回值。同程序一样，日志语句中有的是变我们本以为 log_trace 在 LVL_TRACE 级别被
量（某个变量内容），有的是常量（提示信息）关闭的情况下，消耗的代价仅仅是一个函数调用
。常量你总能从程序源代码中获得，但变量不和分支判断，却没有发现宏参数中还隐藏着一个
行。所以在一条日志中，信息量最大的是变量，需要调用系统调用的函数。当文件不大是还算能
是函数返回值/字符串内容/错误码，因而变量应够忍受，但当这个文件是一个数据库，扫描每一
该尽量放在靠前的位置。常量也不是一点价值没行都要执行两次 log_trace() 时，它对系统性能
有，写得好的提示语句，会使问题一目了然，可的影响就绝不可忽视了。
以免去你到代码中grep，然后重读代码的麻烦。
所以，最佳的做法还是，在性能攸关的代码
上面这两点，几乎所有知道 logging 重要性中，使用可被预处理掉的 logging 语句，仅仅在
的同学都会了解。但关于 logging 对性能的影 debug 发布中才能见到这些日志，release 版本
响，很多人没有足够的警惕心。例如有人会在一中不把它们编译进来。
个按行解析文件的函数中写下这样的日志：
此外，上面这个 log_trace，是一个糟糕的设
int parseline(...) 计。logging 模块只应该干 logging 的事情，开
{ 发人员需要时间统计时会自己完成。 ■
log_trace(“Enter parseline with ...”);
DO_SOMETHING;
log_trace(“Exit parseline with ...”);
return 0;
}

原文：http://blog.solrex.org/articles/on-logging-performance.html


一次博客的性能故障
排查
文／BOYPT

Ubuntu 10.04 这个版本已经服役两年，虽说运算慢是不大常见的，虽说PHP性能一直受到
是LTS，但最近起发现已经有点力不从心，主要诟病。但如果是这个问题是很明显的，top里面
是ppa上一些比较重要的库，如PHP 5.3，ningx的 php的子进程会占满CPU，高居不下。此前排查过
团队已经停止维护，uwsgi则总是落后半年的样一个drupal的站点，是因为前端模板的组件方式
子。很大一个原因是这些包在新版的Ubuntu里面存在循环引用，用profile过程看，正则替换的
已经有官方维护，ppa的第三方维护会缺乏跟 regrex函数占了绝大多的CPU时间。
进。所以在一定意义上，可以宣布Ubuntu 10.04
死亡了。在SSH看到，打开页面的10秒内php-fpm的子
进程基本没占CPU，排除这个可能。
但Ubuntu的包维护策略就是那样，要么自己
维护所有用到的包，要么每隔一段时间就跟着官 IO慢就复杂了，每个组件都有IO，得先确定IO
方一次大升级。觉得不爽就干脆把VPS的系统也的范围。
改成Archlinux。首先想到是数据库Mysql，arch的包太新，有
bug？linode主机的磁盘快挂了，磁盘很慢？这
现象些都不好判断，确定这些得借助工具。
一番大迁移后所有的东西都正常上线，但直 Profiling是追踪一个应用的运行流程，记录
到一个多星期后的昨天晚上才注意到博客的性能所有的函数调用栈、记录调用时间的过程，是追
问题。因为博客那里有nginx直接读取静态的缓查性能问题的最佳帮手。Python里面是有个
冲机制，所以动态执行非常慢之前都没留意到。 repoze.profile的wsgi中间件很方便进行排查，但
我没做过完整PHP开发，就暂时不大清楚有什么
把缓冲关闭就非常明显了，任何一次点击的方便的profile方案（以前弄过早忘了），但
页面都要10秒才能打开。 google一下还是有很多方案的，不过我首先想起
newrelic的应用监控系统就提供了这个功能。
排查
Newrelic针对WEB应用和服务器监控服务，其
引起应用缓慢的因素是非常多的，概括来说中的服务器监控是免费的，但对应用的监控只有
有两种：IO慢、运算慢。 14天试用；所以我赶紧重新申请个帐号，用来监
控一下wordpress。安装好监控模块后，超过2s的
响应会在他们的Transaction traces记录下来。


图表数据可以排除数据库问题，几十个数据 Mar 31 03:17:32 (none) kernel:
库的操作都是在ms级别完成，而在apt-blog.net [17554800.765033] IN=lo OUT=
的耗时花了10秒。其实我一开始对这个报告也没 MAC=00:00:00:00:00:0
看懂，newrelic的直观性还有待提高，其实在这 0:00:00:00:00:00:00:08:00
里出现域名的意思是有网络请求，比如askimet SRC=106.187.36.50 DST=106.187.36.50
的评论、插件的更新等都要和外部请求，这里就 LEN=60 TOS=0x00 PR EC=0x00 TTL=64
会出现域名。 ID=31529 DF PROTO=TCP SPT=45594 DPT=80
WINDOW=32792 RES=0x00 SYN URGP=0
而现在出现了自己博客的域名，那问题就
是，程序里面某个地方需要请求自己的域名，可这里透露了重要信息：
能是检查状态的操作，被卡住了，直到超时才返
回。 IN=lo SRC=106.187.36.50
DST=106.187.36.50
本机程序访问不到本机，基本确定是iptables
规则出问题了，在filter表的最后插入这样一 PHP确实有访问本地网络，送了给lo网
句：卡，SRC和DST都是本地的公网地址。赶紧检查
iptables的规则，果然没了对lo设备的允许规
-A INPUT -j LOG 则。一般配置机器我都是用记录在自己的Wiki的
iptables那套规则的。关于lo的这几句可能一时
iptables的规则一般是，除非明文允许，否则
没仔细想其作用，迁移系统那天脑抽手贱就删掉
拒绝，所以经过一系列的规则后如果还没有没
了。
ACCEPT的，在最后的都是被DROP了，把这句放最
后可以看到究竟是什么包被DROP了。加入允许lo设备的这句：
查看/var/log/everything.log看到这样的记 -A INPUT -i lo -j ACCEPT
录：
至此，问题解决。 ■

原文：http://apt-blog.net/trace_on_a_performace_problem


三招解决MongoDB
的磁盘IO问题文／ nosqlfan

有点标题党的意思，不过下通过上面两种方式存储，预 db.metrics.ensureIndex({
面三招确实比较实用，内容来先一共存储大约7GB的数据（机 metric: 1, client: 1,
自Conversocial公司的VP Colin 器只有1.7GB的内存），测试读 date: 1})
Howe在London MongoDB用户组取一年信息，这二者的读性能
的一个分享。差别很明显：与

申请：下面几点并非放四海第一种: 1.6秒 db.metrics.ensureIndex({
皆准的法则，具体是否能够使 date: 1, metric: 1,
用，还需要根据自己的应用场第二种: 0.3秒 client: 1 })
景和数据特点来决定。那么问题在哪里呢？采用这两种不同的结构，在
插入性能上的差别也很明显。
1.使用组合式的大文档实际上原因是组合式的存储
在读取数据的时候，可以读取当采用第一种结构时，数据
我们知道MongoDB是一个文更少的文档数量。而读取文档量在2千万以下时，能够基本保
档数据库，其每一条记录都是如果不能完全在内存中的话，持10k/s 的插入速度，而当数据
一个JSON格式的文档。比如像其代价主要是被花在磁盘seek 量再增大，其插入速度就会慢
下面的例子，每一天会生成一上，第一种存储方式在获取一慢降低到2.5k/s，当数据量再增
条这样的统计数据：年数据时，需要读取的文档数大时，其性能可能会更低。
更多，所以磁盘seek的数量也
{ metric: 越多。所以更慢。而采用第二种结构时，插入
“content_count”, 速度能够基本稳定在10k/s。
client: 5, value: 51, 实际上MongoDB的知名使用
date: ISODate(“2012-04-01 者foursquare就大量采用这种方其原因是第二种结构将date
13:00”) } 式来提升读性能。见此字段放在了索引的第一位，这
{ metric: 样在构建索引时，新数据更新
“content_count”, 索引时，不是在中间去更新
2.采用特殊的索引结构
client: 5, value: 49, 的，只是在索引的尾巴处进行
date: ISODate(“2012-04-02 我们知道，MongoDB和传统修改。那些插入时间过早的索
13:00”) } 数据库一样，都是采用B树作为引在后续的插入操作中几乎不
索引的数据结构。对于树形的需要进行修改。而第一种情况
而如果采用组合式大文档的索引来说，保存热数据使用到下，由于date字段不在最前
话，就可以这样将一个月的数的索引在存储上越集中，索引面，所以其索引更新经常是发
据全部存到一条记录里：浪费掉的内存也越小。所以我生在树结构的中间，导致索引
们对比下面两种索引结构：结构会经常进行大规模的变
{ metric:
化。
“content_count”,
client: 5, month: “2012-
04”, 1: 51, 2: 49, ... }


“组合式的存储在读取数据的
时候，可以读取更少的文档数
量。”

3.预留空间 db.metrics.insert([
{ metric: ‘content_count’, client: 3, date:
与第1点相同，这一点同样
‘2012-01’, 0: 0, 1: 0, 2: 0, ... }
是考虑到传统机械硬盘的主要
{ .................................., date:
操作时间是花在磁盘seek操作
‘2012-02’, ... })
上。
{ .................................., date:
比如还是拿第1点中的例子 ‘2012-03’, ... })
来说，我们在插入数据的时 { .................................., date:
候，预先将这一年的数据需要 ‘2012-04’, ... })
的空间都一次性插入。这能保 { .................................., date:
证我们这一年12个月的数据是 ‘2012-05’, ... })
在一条记录中，是顺序存储在 { .................................., date:
磁盘上的，那么在读取的时 ‘2012-06’, ... })
候，我们可能只需要一次对磁 { .................................., date:
盘的顺序读操作就能够读到一 ‘2012-07’, ... })
年的数据，相比前面的12次读 { .................................., date:
取来说，磁盘seek也只有一 ‘2012-08’, ... })
次。 { .................................., date:
‘2012-09’, ... })
结果： { .................................., date:
‘2012-10’, ... })
如果不采用预留空间的方
{ .................................., date:
式，读取一年的记录需要
‘2012-11’, ... })
62ms。
{ .................................., date:
如果采用预留空间的方式， ‘2012-12’, ... })
读取一年的记录只需要 ])
6.6ms。■

原文：http://www.colinhowe.co.uk/2012/apr/26/mongodb-strategies-when-hitting-disk/
译文：http://blog.nosqlfan.com/html/3925.html


MySQL数据库中
order by的实现和
by rand() 的优化
文／丁奇

有同学上周问了个问
题“MySQL数据库里面的order
by rand()”是怎么实现的。我
们今天来简单说说MySQL数据库
里的order by。

几种order by的情况
乍一看这个问题好像有点复
杂，我们从最简单的case开始 1、最简单的order —— 序的。就是按照索引a的顺序依
看起。 order by索引字段次读pk的值(在这里是隐藏的系
统列)，一个个从聚簇索引的
用右边这个表来说明：(10w 见下图，从explain的结果来 data中读入。
行数据) 看（Extra列），这个语句并不
作排序。因为字段a已经是有顺

2、复杂一点 —— order by 见下图，这里Extra列显示件排序”，说的就是与上面一
非索引字段一个Using filesort。这里的种情况相比，在Server层作了
filesort并不是指字面上的“文排序。至于是否使用文件，取


决于排序过程中的内存是否足另外一个做法，只读入字段 3、字段函数排序
够，不够则需要临时文件。 b和其对应的主键id。可以想象
为这两个字段构成的结构体，见上图，有这的流程，这里
并不到此为止，我们细细想按照b的值作排序。排序完成就简单了，还是按顺序读入所
一下，MySQL数据库server层要后，按字段b的顺序依次取主键有的字段b，只是sort_keys中
怎么作排序呢？ id，取得结果返回。存的是b的长度而已。
一个简单的想法是把MySQL 实际上第二种作法就是这个
数据库表数据都读到内存，然 4、 Order by rand()
例子中的实际执行过程。存放
后排序。读到内存当然可以想用于排序的字段值的结构我们按照自然想法， order by
怎么整就怎么整。但是这个做称为sort_keys。 rand() 也可以仿照上面描述的
法很耗费内存。需要占用与表做法，对于每一行，将生成的
一样大小的内存。至于order by b,c这样的语 rand()的值放入sort_keys里即
句，效果与order by b相同，可可。但实际上上效果如下：
以简单理解为上面结构体多了
一个字段。

Extra字段里面有一个Using 分析一下这个过程，由于把 order by rand()的改进
temporary，也就是说用到了临数据从InnoDB存储引擎表里面
时表。那么Using temporary的读入临时表，则InnoDB存储引我们前面说过，实际上对于
时候操作流程是怎样的呢？擎表实际上也已经读入内存，这种简单的order by rand() 的
在这个过程中，若不考虑内存情况，也可以等同于按照非索
a) 创建一个heap引擎的临时不够时的写文件策略，则内存引字段来处理。在sort_array
表，字段名为 ”” a b c d, 第中有两份表的全拷贝；另外多中存入随机值即可。
一个字段为匿名; 了从内存中将数据一一拷贝到按照这个思路的patch在这
b) 将表tb中的数据按行读入临时表的过程。里，效果如下图：
到临时表中，同时给第一字段这个查询在我的测试环境中
填入一个随机实数(0,1); 执行时间减少为1.89s，性
耗时2.41s（多次次执行，不计能提升21%, 这个例子单行1k，
c) 按照第一个字段排序，返第一次加载数据的时间）。单行越大提升效果越好。 ■
回
d) 查询完成删除临时表

原文： http://dinglin.iteye.com/blog/1507941


观察思考

阿里巴巴集团去IOE运动
的思考与总结
文／mysqlops

预计2012年5月7日，阿里巴巴集团将正式公 (一) 去IOE事件中的IOE名词解释
布技术团队合并的事情，涉及的部门：阿里巴巴
运维团队、阿里巴巴DBA团队、阿里巴巴平台技 (1).IOE事件中的I是代表IBM的缩写，也即去
术部、大淘宝运维团队、大淘宝DBA团队、大淘 IBM的存储设备和小型机，主要是小型机，阿里
宝核心系统部、阿里云计算运维团队、阿里云计巴巴、淘宝和支付宝主要是使用了IBM的小型
算DBA团队和阿里巴巴集团安全团队，从一些可机，IBM存储设备相对较少；
以猜测到的信息分析，上述技术团队合并之后， (2).IOE 事件中的O是代表Oracle的缩写，也即
大淘宝的员工将成为相关技术团队的掌舵者。去去处Oracle数据库，采用MySQL和Hadoop替代的
IOE政治运动是阿里巴巴集团首席架构师某博士解决方案，Oracle RAC将会被Hadoop集群替代，
主导的，阿里巴巴和淘宝的技术团队内部非常有其阿里巴巴B2B使用的GreenPlum集群，也将会在
影响力的XX负责执行，合并之后阿里巴巴集团内阿里巴巴集团完成运维团队和DBA团队合并之
部所有子公司去IOE运动，将继续深化。个人就后，采用 Hadoop集群解决方案替代；
淘宝、阿里巴巴和支付宝去IOE事件，以局外人
的角度进行利弊分析，希望能达到给明白真相和 (3).IOE事件中的E是代表EMC2,阿里巴巴B2B、
不明白真相群众，一个合情合理中立的分析。淘宝和支付宝都是用大量EMC2的存储设备，也有
少量DELL的存储设备，主要是EMC2,的存储设备
淘宝和阿里巴巴去Oracle化事件引发数据库技性价比高；
术人员大讨论一文，只是把对阿里巴巴、淘宝等
子公司内部非常熟悉的人士观点和建议分别整理 (4).阿里巴巴集团内部最早进行MySQL数据库
出来，以及还有部分外部人士的猜测和分析，本替代Oracle数据库支持数据服务的子公司，是阿
篇文章我们从几个不同的角度综合分析阐述去里巴巴B2B用PC Server替代EMC2,存储设备，替代
IOE事件对阿里巴巴、淘宝等公司的内部DBA团队 IBM小型机。不过替换节凑是被合理控制的，因
价值和意义，对阿里巴巴、淘宝等公司的业务和多方面的原因内部也没有那么雄壮的决心。后
成本影响，对互联网行业的DBA从业者的影响… 来，淘宝也开始进行MySQL数据库的应用摸索和
推广，并且高调宣传去IOE事件，最后造成网络
上满城风雨；

30 观察思考 Linux运维趋势 2012年5月号总第19期

“搭配开发完善的自动化系
统，可以大大简化数据库的管理
成本，也能减少DBA团队的工作
量。”

(二) 去IOE对淘宝、阿里巴巴B2B和支付宝阿里巴巴集团使用License最多的子公司是大
等公司的价值淘宝，2010年及之前，还高调地要部署更多的
Oracle RAC数据库集群，但是在阿里巴巴B2B将中
阿里巴巴集团与甲骨文公司购买的Oracle数据文站压力和数据容量最大的Offer数据库，成功
库是三年无限制性的License，总销价是三年X千从Oracle数据库+IBM小型机+EMC2,存储设备,迁移
万人民币（备注：不能告诉大家具体多少钱，属到MySQL数据库+PC Server的模式，以及大淘宝
于商业机密，望理解！），这部分的开销对整个核心系统部门招聘到@淘宝褚霸、@淘宝丁奇等
阿里巴巴集团而言并不算什么，花费最大地方是能修改MySQL源码和Hbase源码，其他产品线使用
Oracle数据库的座驾，也即主要是IBM小型机和 MySQL数据库提供服务，也使大淘宝的MySQL
EMC2,存储设备的购买费用和保修费用。 DBA的经验和技术大幅提高，大淘宝也就有能力
随着淘宝、支付宝和阿里巴巴B2B的注册用户把产品线的Oracle数据库迁移到MySQL数据库提
数激增，用户产生的数据也越来越多，即使采用供服务，采用Oracle数据库支持的数据分析业务
冷热隔离的方式也解决不了大容量数据且大并发则采用Hadoop集群替代，这是给核心系统部和
的难题，淘宝启用了全亚洲最大的Oracle RAC集 DBA团队建功立业的大好时机，同时能解决大淘
群，阿里巴巴B2B中文站的数据量也因数据量大宝业务系统的压力和瓶颈，也能帮助大淘宝降低
和业务要求，每年早上08:00—09:30之间CPU保持资金投入。搭配开发完善的自动化系统，可以大
98%的使用率，LOAD也超高，即使更换存储设备大简化数据库的管理成本，也能减少DBA团队的
不久也会再次出现这样的状况。互联网行业公司工作量。
迅速发展非常快，集中式数据库系统会逐渐成为阿里巴巴、淘宝和支付宝都曾尝试，将Oracle
业务的瓶颈，不得不面临又喜又忧的事情花费重数据库的座驾AIX系统+ IBM小型机+EMC2，迁移
金升级硬件，这在企业高速崛起的时候，可能不到Linux系统+PC Server的模式。若是对Oracle数
太会在意成本，若是企业占有市场份额足够大、据库不拆分的话，PC Server根本无法承受这样的
步入平稳发展阶段或企业资金出现问题的时候，负载；若是对Oracle数据库拆分，将需要增加购
就不得不考虑企业的成本，那么就不得不考虑采买大量的License；故不得不考虑将业务系统的
用满足企业业务发展需求，企业只需要合理地投 Oracle数据库迁移到开源MySQL数据库和Hadoop
入资金，就不得不考虑更加省钱的数据库软硬件平台上（注释：这2种开源产品能满足业务需
解决方案。求，以及相对其他开源产品更稳定和成熟）。
大淘宝、阿里巴巴B2B和支付宝等公司，98% 非常遗憾的是，阿里巴巴集团首席架构师王
以上的软件系统和业务都是采用Oracle数据库提坚推行的是全面去商业数据库产品计划，也即整
供数据服务，电子商务领域阿里巴巴集团旗下公个阿里巴巴集团，可能除支付宝少数业务的数据
司拥有的总数据量和用户量是其他任何公司无法库继续采用Oracle数据库之外，其他的一切都将
比喻的，DBA团队面临的压力盒挑战也是其他公转换成MySQL数据库，为此可能导致阿里巴巴DBA
司无法比喻的，肯定要比联网其他公司更早关注团队、大淘宝DBA团队、支付宝DBA团队等，在
此方面的资金需求和业务双重压力。 Oracle数据库领域积攒十年的架构设计和运维维
护经验，将瞬间付之东流，同时这些DBA团队的
Oracle DBA也将会有不少人员选择离开，否则只
能转行为MySQL DBA。


“大淘宝是去IOE最迅速最彻底
的公司，相关技术人员也将会得
到更多的晋升和加薪机会。”

大淘宝DBA团队、阿里巴巴DBA团队、支付宝 (三) 去IOE对淘宝、阿里巴巴B2B和支付宝
DBA团队和阿里云计算DBA团队总共拥有的MySQL 等公司的DBA团队影响
DBA人数，不会超过15人，而Oracle DBA有80人
以上，其中MySQL DBA团队真正能干活的DBA不会大淘宝是去IOE最迅速最彻底的公司，相关技
超过X个人，MySQL数据库在阿里巴巴真正支持业术人员也将会得到更多的晋升和加薪机会，阿里
务发展的时间不超过3年（注释：淘宝成立初期巴巴B2B DBA团队很早进行的部分业务系统去
采用MySQL数据库，能力的问题而不得不迁移到 IOE，使得相关人员受益（注释：也包括我个
Oracle数据库平台；阿里巴巴B2B在2009年之前，人，阿里巴巴B2B对MySQL DBA的渴望而有机会加
也是少数边缘业务从Oracle数据库迁移到MySQL 盟，机缘巧合是MySQL数据库成功使用之后离开
数据库平台）。多数是Oracle DBA转行为MySQL 了），而支付宝是去IOE进展最慢的公司，为此
DBA的兄弟，他们在Oracle数据库方面确实经验高层不得不选择派遣相关人员，加速支付宝公司
丰富和能力超强，但是MySQL数据库方面就不多去IOE。
加评论… 阿里巴巴集团最后可能保留少数业务产品
小结：线，继续使用Oracle数据库平台提供数据服务，
以及MySQL数据库的自动化完成之后，将导致阿
一直为MySQL社区的发展与壮大而努力，作为里巴巴集团DBA团队出现资源严重富余，Oracle
技术人员要说真话和大实话，不能因个人感情而数据库迁移MySQL数据库过程与完成之后，将会
做事情。个人认为阿里巴巴集团去IOE是不得不出现DBA人员的流失，这对阿里巴巴集权的DBA团
要做的事情，但不是把所有的Oracle数据库都迁队而言是一种损失，往往选择离开的Oracle
移到MySQL数据库或Hadoop平台，而应该是对业 DBA，越是优秀和有成长潜力的，可能早就更多
务系统有选择地进行，以及迁移的步调要合理地 DBA人员处于混日子的状态。
控制，不宜过快过急，需要等待MySQL数据库DBA
团队的壮大，技术与经验的积累。否则，可能出去IOE事件对MySQL团队和核心系统部门的发
现迁移过去之后不久，发现对业务发展和支持出展，是非常有利和促进作用。越来越多的业务系
现严重的问题，大淘宝内部的信息分析，他们已统和核心系统，采用MySQL数据库提供数据服
经基本度过危险的阶段，也有很多遇难杂症，但务，MySQL DBA面临的挑战与压力将会越来越
是支付宝的业务具有特殊性，要比淘宝的业务系大，DBA团队的自动化水平能力也将会迅速得到
统要求更高，恐怕是一个非常大的障碍。提高，否则无法管理规模庞大的MySQL数据库集
群和Hadoop集群。
阿里巴巴集团高调向外界传递去Oracle数据库
信息之后，新的Oracle数据库License谈判将会很整个阿里巴巴集团能读懂、编写和优化MySQL
变得艰难，甲骨文公司本来是把把阿里巴巴、淘源码的DBA或开发人员，总数不会超过X个人，这
宝和支付宝等公司作为中国标杆用户宣传，现在对阿里巴巴集团去IOE也是一项挑战，毕竟开源
公开大规模地去Oracle数据库，可能会得到甲骨数据库产品没有商业数据库产品那样经过严格的
文公司的报复，为此可能要偿付更加昂贵的测试流程而稳定，购买甲骨文官方提供的MySQL
License费用。对于阿里巴巴价值观“拥抱变服务，绝对不是淘宝、阿里巴巴和支付宝DBA团
化”，是无处不体现，但是要合理地使用，不要队的行事风格，一定会想办法自己修改和优化
被某些人利用搞成政治运动，而影响企业的稳定 MySQL源码，相信阿里巴巴集团会投入更多的资
与发展。源引进相关的技术人才，这对MySQL团队的技术
提高也非常有帮助。 ■

原文：http://www.mysqlops.com/2012/05/07/alibaba-ioe.html

32 观察思考 Linux运维趋势 2012年5月号总第19期

《Linux运维趋势》2012年5月号总第19期

《Linux运维趋势》2012年5月号总第19期

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (20)

Similar to 《Linux运维趋势》2012年5月号总第19期

Similar to 《Linux运维趋势》2012年5月号总第19期 (20)