Linux运维趋势_第4期_性能瓶颈

内容目录【人物】系统运维经验分享：守住每一天...........................................................................................................3【交流】系统运维秘诀：变化，监控，扩展（技术篇）..................................................................................5【八卦】八卦，趣闻与数字2010.12-2011.01.............................................................................................10【专题】为什么进行Linux性能监测？.............................................................................................................11细数十个最令人头疼的性能瓶颈.........................................................................................................14Linux磁盘管理三板斧的使用心得......................................................................................................16系统负载：如何判断Linuxload的值是否过高...............................................................................19【技巧】在linux下灵活使用expect脚本的小窍门.......................................................................................21系统管理员易犯错误及解决方法汇总................................................................................................23系列连载：最牛B的LinuxShell命令（2）....................................................................................26杂志策划：51CTO系统频道本期主编：杨赛封面制作：高鹏飞交流圈子：邮件群组：groups.google.com/group/linuxops-cn订阅方式：发送Email到[e-mail]专题页面：://down.51cto.com/zt/71投稿信箱：[e-mail]人物People维是一个所含范围很广泛的职业，在不同的企业、不同的工作环境下，运维的职责可能是完全不同的。即使单就系统运维而言，有些运维可能专注于内网服务器的维护，工作偏向网管和帮助台的职责；有些运维可能从开发环境、数据库到线上应用部分都负责；有些可能仅仅负责特定应用的运维。所以，即使是在职的系统运维，也可能对这个行业的同行们的工作内容了解有限。运为此，51CTO系统频道计划展开一项长期活动，请各个岗位上的、有数年运维经验的在职系统运维们分享他们自己的成长经验。本次我们邀请到新浪系统运维工程师、LinuxTone的管理员刘宇（守住每一天）来分享一下他的运维经验。51CTO：首先，简单的跟我们介绍一下您现在的工作情况吧。您现在负责哪方面的工作？守住每一天（以下简称守住）：我是在门户网站做Linux运维嘛，现在做CDN运维这块。近期核心主要放在集中化管理，分布式监控，和分布式日志系统上。51CTO：您最初接触Linux是什么时候？最开始做运维这个工作是从什么时候开始的？守住：我是03年开始接触linux，那时主要是自学。也没怎么去论坛交流之类的。从事工作是在07年，这个过程倒是还挺顺利的。主要是诚恳，踏实，肯学，底子要打好。这样的小伙一般企业都会要的。51CTO：一开始做运维的几年，有什么印象深刻的事情吗？守住：刚开始做的时候很难，遇到问题时，总是喜欢问人。不先查文档。这是一个很不好的习惯。后来慢慢改了：）最痛苦的是最开始工作那会儿，刚接手设备的时候，一下遇到3台机器陆续宕机。不是硬盘故障，就是主板故障，最终换新设备，迁移解决。这么折腾一大圈，一下子就让我接触到了故障分析、服务器迁移方面的很多东西。“守住每一天”的意思就在这里：每天要做一件满意的事件，那怕一天就解决一个问题。系统运维经验分享：守住每一天文字整理/杨赛人物简介：刘宇，网名守住每一天，现新浪运维工程师，LinuxTone.org管理员之一，擅长CDN运维。目前关注集中化管理，分布式监控，以及分布式日志系统。他的博客：://g.51cto.com/linuxops/投稿信箱：[e-mail]3人物People51CTO：您自己感觉在您的运维经历中，哪段时间是您成长最快的？那段时间您关注的技术点主要是哪些？有什么人提供指导或是交流吗？守住：压力越大，成长越快。我成长也就是08年的时候吧。当时整个公司的网站迁移、升级，从机房选择一直到全部迁移升级完成，都是我一个人，压力相当大。那会儿主要是关注负载均衡的部署。秋香给我帮助挺大的。51CTO：有什么对您帮助特别大的技术书籍么？或者文章/讲座？守住：书我看得少~人懒，网上的文案看得多。然后再实践，再找相关的书进行一个系统的学习。我喜欢反着来，对我来说效率更高吧。有关文案这方面可以给大家一些建议：我一般的学习方法是，先阅读官网README，再看WIKI，再看INSTALL，这就差不多了，可以准备动手操作。所以英文一定要有些基础。如果感觉英文吃力，那就只好搜索相关的中文做参考了。国内很多文档都有问题，尤其是那些瞎搜索出来的，所以建议大家选择比较靠谱的论坛或网站搜索，比如国外有howtoforge，allcommands，cyberciti等，国内就是CU，51CTO，LinuxTone这些我比较常去。51CTO：说说LinuxTone.org这个站吧。当初建立这个社区是怎样的一个情况？主要是针对哪些层次的Linux技术人的？守住：2008年那会儿，netseek创立了这个站，我也是同年加入管理团队的。正如同LinuxTone的建站宗旨说的，我们主要专注于系统服务、集群架构、安全监控、性能调优程序设计这些方面，算是比较偏中高端的综合IT运维人员吧。51CTO：您认为一个理想的Linux运维交流社区应该是怎样的？守住：还是那句话：“我为人人，人人为我”。每个人因为分享自己的经验获得快乐，我认为就是理想的社区。51CTO：最后，介绍一下您现在的关注方向吧。2011年您在技术上和个人成长上有什么计划么？守住：技术方面，主要还是集中化管理，分布式监控，和分布式日志系统方面的继续深入具体计划方面其实我是没有的。我觉得计划不如变化。“守住每一天”的意思就在这里：每天要做一件满意的事件，那怕一天就解决一个问题。计划得再好，也赶不上你遇到的问题。有些时候一个问题解决就需要几天，那你的计划就全打乱了。今日事今日毕。早上在地铁里想好今天做什么，下班地铁记录今天做的工作这样就OK了。手机和GOOGLE如此方便。有什么不方便的呢？51CTO：感谢守住每一天的分享！本次内容到此结束。如果您有什么问题想要沟通，或者希望听到某个运维进行分享，欢迎与守住或编辑交流。原文：相关推荐：系统管理员访谈系列：TomLimoncelli谈交流://g.51cto.com/linuxops/投稿信箱：[e-mail]4交流Interact运维管理的过程中，我发现了很多有价值的秘诀，本文是这些秘诀的一个总结。虽然这些秘诀可能比较“唯心”，但是我还是把它们总结出来了，相信它们会对你有帮助的。在为变化而设计◆Google的秘诀是正确的——“为变化而设计”。“变化”就是不得不部署新的软件，升级现有的软件，进行扩展，设备损坏，以及人员流动等。◆每一件事情都是在寻找平衡点。你也许会认为把你的系统和某个操作系统或某个Linux发行版牢牢地绑定在一起是一个好主意，但事实上这跟把它们完全隔离一样糟。如果实在有必要，你可以进行分层，并使用一点间接性。◆这并不意味着你的系统必须是平台无关的其实我们的目的很简单：一变二，二变二十，一个系统必须可以应对各种突发事件。也就是说，如果一个系统管理员被公共汽车撞了，你有应对的方案！如果挂载的硬盘出现故障了，你有应对的方案！如果某些人运行了rm-rf/，你也有应对的方案！增量的进行变更。记得安全更新，以及保持内容更新。使用自动的，可重复的构建过程◆不要手动构建任何东西。如果你一定需要手动构建，那么就做两遍，在做第二遍的时候把用到所有的命令都提取出来。◆下面这一点十分重要：将新硬件上线到生产环境的过程不应该超过15分钟，而且这个过程必须足够简单。否则，当一个服务器出现故障，而没有人知道如何更换它的时候，你就该倒霉了。◆下面这一条是普世真理：这个世界上不存在“一次性”的服务器构建。即使你的服务器只需要构建一次，但只要你构建过一次，就一定会有第二次。比如，当它损坏的时候，或者你必须进行一次重大的升级才能让它在在接下来的两年时间里更加稳定的时候。◆测试，检查新构建好的服务器。这应该是比较容易的，因为你的构建过程都是自动化的对吧！◆脚本化的构建，意味着从某个Linux发行版的V3升级到V4应该是很快的。安装V4，对脚本进行测试。如果有问题，参考文档并修复它，直到它可以再次正常工作。这最多应该是一个星期的工作，而不是一个长达一年的浩大工程（因为那时，刚刚完成的V5已经发布了！）不要手动构建任何东西。如果你一定需要手动构建，那么就做两遍，在做第二遍的时候把用到所有的命令都提取出来。系统运维秘诀：变化，监控，扩展（技术篇）文/Dormando编译/周雪峰5://os.51cto.com/linux/投稿信箱：[e-mail]交流Interact使用冗余◆容易重新构建，并不意味着你可以忽视冗余。跳转盒，邮件服务器，计费网关，等等。如果其中的一半挂掉了却并不造成客户的宕机生活将会变得更加简单。◆按照以上方针来做的话，当某个设备在凌晨3点出现故障的时候，你可以“以后再处理那个出现故障的设备！”，把冗余的机器先替换上去。◆下面这一条是个聊胜于无的解决方案：Rsync。DRBD也许也不是一个完美的解决方案，但是它可以提供令人称奇的服务。使用备份◆备份是个严肃的话题。使用硬盘，烧录磁带。压缩它们，移动它们，并行地运行。对每一样东西进行备份！◆如果你的构建过程是自动的，整个过程都可以被备份。如果到目前为止的几条你都做到了，那么一个真正的“灾难恢复”计划也许并不是那么遥不可及的。监控正确的东西◆监控你能监控的所有东西，而且要用正确的方法