51CTO下载-Linux运维趋势_第12期_故障排除

002《Linux运维趋势》投稿信箱:[e-mail]杂志订阅:频道：目录Index002目录人物·People003天涯首席工程师王建科：技术人要有产品观交流·Interact005网站扩展实例:1亿用户的Tagged架构进化史八卦·News007Linux20周年庆，2011最佳开源软件专题·Special009strace命令使用实例010Unix调试的瑞士军刀：lsof012使用top命令的一些小技巧013网站排障分析常用的命令014MySQL生产环境突发故障处理手册016oracle审计导致的系统性能故障017数据库故障分析与排查技巧·工具·脚本021Linux管理员常用网络资源收集022五款救急的Linux文件恢复软件024运维自动化之Cobbler系统安装详解027用SHELL脚本来防止SSH和vsftpd暴力破解出版方：51CTO系统频道（北京无忧创想信息技术有限公司）本期责编：李晶杂志主编：杨赛联系方法：[e-mail]010-68476606（分机8035）出版日期：2011年9月16日每月第2个星期五出版订阅：《Linux运维趋势》投稿信箱:[e-mail]杂志订阅:频道：人物People003天涯首席工程师王建科：技术人要有产品观国内的网民们大多听说过天涯社区，只是也许很多人并不知道，这个有12年历史的、现在同时在线已经超过50万人的巨大社区，在最开始几年的产品设计、开发和运维，都是由一个人来完成的。他就是现在天涯的首席工程师、天涯论坛产品总监王建科。本次访谈内容大致分为天涯的技术发展历程、天涯界面的设计、对技术债务的观点、对技术选型的观点、对技术人员成长的建议、以及开源相关的一些话题。对于互联网行业的开发、运维和产品运营人员而言，相信王建科的分享会给你带来一些启发。51CTO：首先，简单的介绍一下天涯的技术发展历程吧。王建科：天涯最初只有一个开发者，就是我。产品的设计和技术实现都是我。当时是用ASP来做，有很多困难，因为那时ASP这个技术没有文档，全靠摸索，不像现在，网上资料非常多。那是在98年底的时候。天涯最开始上线运营的话是99年3月1号。我的ID是2月28号注册的，是天涯第一个ID。回想当时，其实对技术的要求并不很高，只要把这个东西实现出来，快速的实现出来。当时整个互联网的网民也比较少，所以用户比较少，所以对整个性能的压力也比较小。当然服务器硬件也比较差，大概是586这样的吧。51CTO：当时服务器是托管在机房？王建科：当时我们还没在机房，只有一条链路，好像也就是几十K吧，马上感觉不够，就搬到电信的机房去了。当时电信还没有IDC这个概念，也就是一张桌子，有个网线，连上去就行了（笑）。当时门槛是比较低的。我们把天涯分为几个阶段，第一个就是2003年之前，刚起步的一个阶段。网民比较少，当时网友还是一个比较异类的人群，ID千奇百怪的，谈的话题别人都听不懂。所以那个时候，同时在线也就是90人左右。2002年同时在线是1000人，到2003年的时候，同时在线就差不多快要10000人了。不过2003年那时候还是只有一台服务器，又当web又当db，内存只有512MB，这个压力可想而知。当时天涯还有一个特点，就是帖子是不分页的。一千回复也好，一万回复也好，一个页面都要全部加载进来。长帖对天涯的系统压力非常大。2003年之后到2006年之间，是天涯发展的一个中期阶段。这个阶段天涯快速发展，从2003年的同时在线8000人，到2006年达到20万。快速发展我觉得有几个原因吧，第一个是大概在2005年左右，中国互联网快速增长，网民大爆发，天涯用户也跟着往上增长。还有一个就是当时天涯的媒体性凸显出来，因为天涯当时很多网络事件和话题，很多媒体就把天涯作为一个新闻源去报导，这样相当于传播天涯的品牌。这样就导致了天涯的快速增长，而天涯的服务器这时候增长的也比较快……51CTO：不再是一台服务器了。王建科：嗯，不再是一台了。2004年的时候，已经是4台web，2台db了。之前已经是扛不住了，负载全都满了这么一个状况。后来我们就拆分嘛，把db拆分。天涯不是论坛分很多版块吗，所以就是把不同版块拆分到不同的服务器上。如果是所有版块在一个表里的话就很难拆分，所以我们就是一个版块对应一套表。所以如果这个服务器压力比较大的话，我们就可以把一整个版块，就是一个表，迁移到别的服务器上去。所以db方面就是按版块拆分表这个模式。web方面就是增加。现在web方面扩展比较容易点，最采访/杨赛人物简介：王建科（天涯ID：卓锐），1996年毕业于吉林大学计算机科学系，现任海南天涯在线网络科技有限公司首席工程师、天涯论坛产品总监，天涯早期建设者及参与者，主导开发了天涯论坛、天涯博客等产品。004《Linux运维趋势》投稿信箱:[e-mail]杂志订阅:频道：人物People004早做的时候就是通过session会话把web进行拆分。db另一个方面就是不使用连合查询。天涯最早为了优化性能有几个特点，一个就是不使用连合查询。比如有的时候你要呈现用户的名字啊，标题等信息的时候，就要去读，那么我们的做法是在产生的时候就把信息写到同一个地方去了，读的时候就只要把它一起呈现出来。这样表之间就没有太多关联，因为表关联也是十分影响性能的。而且表关联还会造成难以拆分的问题。还有就是一帖到底这个，我们的做法就是把所有回复写到一个字段里面去。有新的回复时，就把这个内容插到字段最下面，这样呈现的时候，只要读一个字段就全出去了。这样就极大的降低了db的I/O，因为多一次读写就多一次I/O嘛，你只有一个字段，就只有一个I/O；如果100个回复分为100个字段，那就是100倍的I/O，1000个就是1000个I/O。所以天涯把所有回复合并，就极大的减少了I/O。所以天涯才能大体做到“一帖到底”，不分页。另一个有关这个分页。很多论坛数据量很大的时候，你越往后翻页，处理的速度就越慢，效果很差了。所以天涯这边我们用where子句来分页。Where子句就是判断，你点下一页的时候，用where子句定位到这个下一页的数据。所以这样的话，你每次点下一页，每次请求在性能上的消耗都是一样的，一致的。51CTO：就不用做n次计算了。王建科：对，就不用再去计算我下一页这个数据到底在什么位置，尤其数据量大的时候，这就很快。当然天涯只提供了下一页的功能，而没有提供直接到某一页的功能，就只能一页一页翻这样。另一个就是锁。很多网站采用了死锁这种机制，但是天涯呢，因为网友看内容对一致性的要求并不高，我们就都全部允许脏读。就是说你不用忽略这个更新，不用在读的时候把它锁上这样。51CTO：因为没这个需要。王建科：对，没必要。因为我们的数据不像银行数据，对一致性要求并不特别高，就避免了死锁这样的方式。另外一方面就是我们也用了DNS轮询，但是DNS轮询这个效果并不是特别好，没有我们想象的那么均匀，所以后来我们就自己写了应用来控制负载均衡。另一个就是在2003年后来压力大的时候，我们开始用Squid做页面缓存。当时因为天涯很多动态的内容，变化比较大，而用了页面缓存之后，命中率在70左右吧，还不错，减少了后端的很多压力。这样就是2003年到06年这个阶段。那么07年到现在呢，就是比较强调架构化这个方面。07年之前我们不是只有电信这么一个链路吗，网通用户就抱怨很多，所以就购买了网通链路，然后用F5做链路负载均衡。然后就是做更多的页面缓存。Squid之后我们开始用Varnish，这个感觉效果更好一些。然后就是对页面进行压缩。因为天涯都是文本内容嘛，所以压缩率能达到70%，效果挺好。然后就是memcached内存缓存，就是你要往db读写的内容都先放在memcached里面，这个命中率比较高，有90%。所以就是一步一步做过来，先解决网通用户的抱怨，再整个做优化。51CTO：您对技术人员在中国的发展有何看法？王建科：在中国的话，技术人员在大企业成长的空间会更大一点，在中小企业的成长空间就会小一点，这是中国技术人员面临的一个问题。51CTO：意思是中国的技术人员还是尽量在大企业寻求发展是吗（笑）？王建科：这个嘛（笑），比如像我的话，其实从一开始就是同时做技术和产品两条线。很多技术人员要往产品的方向转，觉得有很大困难，但是我这边就要求，技术人员也必须关注一些产品，因为接触过产品的技术人员思考交流的方式跟没接触过产品的技术人员是不一样的。他能够考虑到一个产品使用会不会有问题，技术特点方面能不能作出更漂亮的功能。像是国外很多互联网产品都是技术人员驱动的，好比Google这样的。那么我也会鼓励我们的技术人员，多关注产品，参与一些决策。否则的话，现在很多公司一个常态就是，运营人员埋怨产品，然后技术就成了推脱责任的借口，我们叫做“炮灰”（笑），很辛苦，又没有成就感。这是不利的，所以就想怎么把这部分和运营团队糅合在一起，共同做一件事情，共同关注用户。这是知识面方面。另一方面技术人员也要扩展一下深度，还是要走专业化的路线。所以我们也鼓励技术人员进行交流，好比刘天斯，就很喜欢写博客分享一些东西，这个过程也学到很多东西。本文有删节，完整内容见原文：《Linux运维趋势》投稿信箱:[e-mail]杂志订阅:频道：交流Interact005网站扩展实例:1亿用户的Tagged架构进化史一家2004年创建的试水社交网站，经过7年的成长和扩展，现在已经拥有了1亿用户。平均50亿次的pv，承担在1000多台服务器的网站架构上。Tagged网站，现在承载了1亿个用户、1千台服务器和50亿次页面浏览量。这个过程是如何实现的？本文将要介绍的就是这个叫Tagged的网站——Tagged架构实例：1亿个用户、1千台服务器和50亿次页面浏览量。下面，Tagged的CTO兼联合创始人JohannSchleier-Smith将为我们介绍Tagged网站架构的成长历程。自2004年以来，Tagged从一家试水社交领域的小不点网站，逐渐变成全球最大的社交网络之一，数百万的成员访问该网站以结交新成员，每个月的页面浏览量达到50亿次。这个逐步发展的历程迫使我们Tagged不断完善网站架构，最终获得了功能异常强大的平台。第一个阶段：2004年，PHPWeb应用程序、10万个用户和15台服务器孵化器有着一种快速成型文化：每年通常推出两个新概念，寻觅其中的大赢家。正是在这样的文化中，Tagged应运而生。LAMP是适合这种类型的工作的自然选择；这种工作注重灵活性和快速开发周期。当时，Java开发主要面向大企业的开发工作，Python吸引的编程员寥寥无几，Perl方面的编程员又不是我们所要的那一种。我们还知道，雅虎是PHP的大力支持者；所以一旦有需要，完全有可能扩展业务规模。我在以前的项目上运行MySQL方面有着丰富的经历，这让我对这项技术爱恨交加。本着尝试的精神，我们为Tagged购买了几份入门级Oracle许可证，看看甲骨文的技术是不是用起来更好。值得注意的是，许多构建的小型网站仍然就像早期的Tagged。具有一