原文链接： http://blog.scoutapp.com/articles/2009/07/31/understanding-load-averages

你可能对于 Linux 的负载均值（load averages）已有了充分的了解。负载均值在 uptime 或者 top 命令中可以看到，它们可能会显示成这个样子：

load average: 0.09, 0.05, 0.01

很多人会这样理解负载均值：三个数分别代表不同时间段的系统平均负载（一分钟、五 分钟、以及十五分钟），它们的数字当然是越小越好。数字越高，说明服务器的负载越 大，这也可能是服务器出现某种问题的信号。

而事实不完全如此，是什么因素构成了负载均值的大小，以及如何区分它们目前的状况是 「好」还是「糟糕」？什么时候应该注意哪些不正常的数值？

回答这些问题之前，首先需要了解下这些数值背后的些知识。我们先用最简单的例子说明， 一台只配备一块单核处理器的服务器。

行车过桥

一只单核的处理器可以形象得比喻成一条单车道。设想下，你现在需要收取这条道路的过桥 费 -- 忙于处理那些将要过桥的车辆。你首先当然需要了解些信息，例如车辆的载重、以及 还有多少车辆正在等待过桥。如果前面没有车辆在等待，那么你可以告诉后面的司机通过。 如果车辆众多，那么需要告知他们可能需要稍等一会。

因此，需要些特定的代号表示目前的车流情况，例如：

• 0.00 表示目前桥面上没有任何的车流。 实际上这种情况与 0.00 和 1.00 之间是相同的，总而言之很通畅，过往的车辆可以丝毫不用等待的通过。
• 1.00 表示刚好是在这座桥的承受范围内。 这种情况不算糟糕，只是车流会有些堵，不过这种情况可能会造成交通越来越慢。
• 超过 1.00，那么说明这座桥已经超出负荷，交通严重的拥堵。 那么情况有多糟糕？ 例如 2.00 的情况说明车流已经超出了桥所能承受的一倍，那么将有多余过桥一倍的车辆正在焦急的等待。3.00 的话情况就更不妙了，说明这座桥基本上已经快承受不了，还有超出桥负载两倍多的车辆正在等待。

上面的情况和处理器的负载情况非常相似。一辆汽车的过桥时间就好比是处理器处理某线程 的实际时间。Unix 系统定义的进程运行时长为所有处理器内核的处理时间加上线程 在队列中等待的时间。

和收过桥费的管理员一样，你当然希望你的汽车（操作）不会被焦急的等待。所以，理想状态 下，都希望负载平均值小于 1.00 。当然不排除部分峰值会超过 1.00，但长此以往保持这 个状态，就说明会有问题，这时候你应该会很焦急。

「所以你说的理想负荷为 1.00 ？」

嗯，这种情况其实并不完全正确。负荷 1.00 说明系统已经没有剩余的资源了。在实际情况中 ，有经验的系统管理员都会将这条线划在 0.70：

• 「需要进行调查法则」： 如果长期你的系统负载在 0.70 上下，那么你需要在事情变得更糟糕之前，花些时间了解其原因。
• 「现在就要修复法则」：1.00 。 如果你的服务器系统负载长期徘徊于 1.00，那么就应该马上解决这个问题。否则，你将半夜接到你上司的电话，这可不是件令人愉快的事情。
• 「凌晨三点半锻炼身体法则」：5.00。 如果你的服务器负载超过了 5.00 这个数字，那么你将失去你的睡眠，还得在会议中说明这情况发生的原因，总之千万不要让它发生。

那么多个处理器呢？我的均值是 3.00，但是系统运行正常！

哇喔，你有四个处理器的主机？那么它的负载均值在 3.00 是很正常的。

在多处理器系统中，负载均值是基于内核的数量决定的。以 100% 负载计算，1.00 表示单个处理器，而 2.00 则说明有两个双处理器，那么 4.00 就说明主机具有四个处理器。

回到我们上面有关车辆过桥的比喻。1.00 我说过是「一条单车道的道路」。那么在单车道 1.00 情况中，说明这桥梁已经被车塞满了。而在双处理器系统中，这意味着多出了一倍的 负载，也就是说还有 50% 的剩余系统资源 -- 因为还有另外条车道可以通行。

所以，单处理器已经在负载的情况下，双处理器的负载满额的情况是 2.00，它还有一倍的资源可以利用。

多核与多处理器

先脱离下主题，我们来讨论下多核心处理器与多处理器的区别。从性能的角度上理解，一台主 机拥有多核心的处理器与另台拥有同样数目的处理性能基本上可以认为是相差无几。当然实际 情况会复杂得多，不同数量的缓存、处理器的频率等因素都可能造成性能的差异。

但即便这些因素造成的实际性能稍有不同，其实系统还是以处理器的核心数量计算负载均值 。这使我们有了两个新的法则：

• 「有多少核心即为有多少负荷」法则： 在多核处理中，你的系统均值不应该高于处理器核心的总数量。
• 「核心的核心」法则： 核心分布在分别几个单个物理处理中并不重要，其实两颗四核的处理器 等于 四个双核处理器 等于 八个单处理器。所以，它应该有八个处理器内核。

审视我们自己

让我们再来看看 uptime 的输出

~ $ uptime
23:05 up 14 days, 6:08, 7 users, load averages: 0.65 0.42 0.36

这是个双核处理器，从结果也说明有很多的空闲资源。实际情况是即便它的峰值会到 1.7，我也从来没有考虑过它的负载问题。

那么，怎么会有三个数字的确让人困扰。我们知道，0.65、0.42、0.36 分别说明上一分钟、最后五分钟以及最后十五分钟的系统负载均值。那么这又带来了一个问题：

• 我们以哪个数字为准？一分钟？五分钟？还是十五分钟？ *

其实对于这些数字我们已经谈论了很多，我认为你应该着眼于五分钟或者十五分钟的平均数 值。坦白讲，如果前一分钟的负载情况是 1.00，那么仍可以说明认定服务器情况还是正常的。 但是如果十五分钟的数值仍然保持在 1.00，那么就值得注意了（根据我的经验，这时候你应 该增加的处理器数量了）。

• 那么我如何得知我的系统装备了多少核心的处理器？ *

在 Linux 下，可以使用

cat /proc/cpuinfo

获取你系统上的每个处理器的信息。如果你只想得到数字，那么就使用下面的命令：

grep 'model name' /proc/cpuinfo | wc -l

- eof -

译注：开发人员如何从无休止的需求、项目进度中摆脱烦躁的心态，这是每个人都值得思考的话题。无意间看见了 这篇文章 ，恐于太长遂将其精简翻译，错误之处难免欢迎指正。

同时如果你有有关程序员修身养性的观点和心得，欢迎说说你的看法。

-- Split --

其实每个程序员或多或少都会有个毛病，就是具有某种有强烈的「优越感」。而这种「优越感」 有可能成为激励自身不断发展的动力，同时也有可能成为其职场中的绊脚石。

程序员的这种心态，源自自身掌握的技术、以及多年积累的经验。正如上面所言，这种心态 能使其一切都力求完美、同时准确按照自己的思路行事，能使其技术不断的提升。而另一方 面，如果将这种态度套用给身边其他的人（包括陌生人、同事、朋友甚至家庭），则会发现 他的生活将会如履薄冰 -- 他们只会看见完美的一面而忽略了更多更需要关注的事物。

总而言之，越早发现并解决这一问题，越对自身有利。套用 GeraldWeinberg 在 《计算机编程心理学》 中的一段话

这种想法是程序员必须解决的，他们对待自己的代码犹如对待自己身体的
一部分，因此他们拒绝所有的负面评价。相反，它们（指代这种心态）应
该及时的引导到正途，使其发挥真正的效用。人非圣贤，这不仅仅是心态
更是精神上的境界，并非所有人都能达到，但仍旧值得去尝试。

症状

那么，你如何得知这种「优越感」正在伤害到自己？除了应付那些没完没了的催促项目进度的 电话，以及给同事擦屁股的优化工程，其它的现象并非显而易见。

其实就我个人而言，时常也会自我责备，这就能窥出事态的严重。例如一方面你对项目疲于 奔命，而同时却忽略身边的人对你表达的看法（该死，这个时候我应该放下手头的工作听他 们说完的）。或者你「假装」静下心来听取他们的意见，但不就繁杂的工作却让你左耳进右耳 出。

其他的些症状

• 如上面所说的，不会妥善处理批评
• 不放心同伴的代码，经常性地对他们进行代码审查（Review）
• 报复性的编写大量充斥着错误的代码
• 个人的消极心态，对自身和团队造成不利的影响
• 必须要求进行测试，但出发点却是炫耀
• 对事物的看法仅仅局限于个人或者本职位的角度

这不仅仅是你个人的事情，编程以及项目开发实际上是团队活动。了解到这些，你将会意识到 你的心态将会直接影响到你的同事。

事实就是这样，当我对您的代码提出写意见甚至批评时，你应该听、并且认
真的听，这样你才能理解我的看法。

有可能最糟糕的情况就是，即便早已经收到其他同事的提醒，当事人已经陷入此泥潭无法自拔。

准则

让我们回到文章的题目本身，正如上面的例子中看到，「谦逊编程」不是编程技术本身，而是 种态度，但它的确会比你掌握的某种技术要有用的得多。

行为准则的确能改变人的心态，下面是些不成文的建议，或许你可以尝试下

• 不要草率的宣布你的决定，在大多数情况下，你应该和你们的同事们讨论
• 不要使用这些论调，这非常让人感到不适：「这是见过的最糟糕的代码了」，换之你可以这样说，「我有个更好的解决方案，要不看看？」
• 不要轻易认为他们没有考虑到你想的方式，即便很不幸是这样，应该善意的提醒。例如「你觉得我这个看法怎么样...」
• 不要无理由的批评你认为很弱智的现象，例如「我觉得 DBA 脑门子被夹了，这个字段竟然使用 INT 型」

更多的，可以参考 Tech Republic 中的 「谦逊编程」十条诫律 ：

• 理解和接受你将犯下的「错误」。

重点是及早的发现你已经犯下的错误，当代码投入使用以后，改动起来就会非常的困难。

• 你的代码不能代表你的人。

记住始终要 Review 你的代码，即便你已经认为无懈可击，经验证明总能发现些错误。

• 不管怎么样，有些「奇技淫巧」总能派上用场，而可能这些技巧别人知道的比你更多。

如果你坚持不耻下问，你的同伴总能分享你更多。

• 不要在完全没有沟通的情况下，自作多情的进行代码重构。

当你确定要更改别人的代码时，必须加上良好的修改记录，这也是出于对他人的种尊重。

• 对待那些新手要保持充分的尊重、细心以及耐心。

记住当他们成长起来后，能帮你解决的问题会比你想象中的还要多。

• 唯一不变的是变化。

怀着开放的心态对待变化，对于各种需求、平台甚至开发工具的变更，应该是迅速适应而不是牢骚满腹 -- 这样解决不了问题。

• 真正的权威来自学识，而不是立场。

权威源自学识、尊重源自权威。

• 优雅的接受失败。

最终你的一些观点将会被推翻，即便你有能力证明你的观点是正确的，请不要重复的争辩。帮助其他人意识到这点的最好工具，就是你的理解以及时间。

• 不要成为「办公室男」。

不要在昏暗的办公室里独自喝着可乐敲着代码。当与外界隔绝，离开同伴的视线，也就说明你离开了一个开放、合作的环境。

• 批判代码而不是编写它的人。

要知道你的意见可以影响到代码也可以影响到其人，如果你想尝试下如何打击别人的自信并造成冲突，那么尝试下吧。

观察了好久，终于下决心出手了，本来想买款单反相机，但发现其实长焦相机更适合我。

冒着杭州将近 40 多度的高温，到文三路将 其 取了回来，卖家很抠不送 UV 镜头和三脚架，所以这些就另外配了，总价 2500 上下，这也符合我的预算。

相机的属性还不是很熟悉，放几张样片让大家评论下吧

不管怎么样，现在至少外出有个偷拍利器了，啥时候可以约上 ppeng 等人去西湖扫街了。