理解 Linux 的处理器负载均值 + 续

原文链接: 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 的话情况就更不妙了,说明这座桥基本上已经快承受不了,还有超出桥负载两倍多的车辆正在等待。

https://i-blog.csdnimg.cn/blog_migrate/6a20ee889240ddb3937ff167923a4138.png

上面的情况和处理器的负载情况非常相似。一辆汽车的过桥时间就好比是处理器处理某线程 的实际时间。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 就说明主机具有四个处理器。

https://i-blog.csdnimg.cn/blog_migrate/5a5a8a3e27bee28cc0672b41cbb85017.png

回到我们上面有关车辆过桥的比喻。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

§ 21 条评论

    1. wiLdGoose wiLdGoose

      最近明爷人品大爆发啊,沙发。

    2. 文章很好,例子很好,让人一看就明白。有厚积薄发之感。

    3. 恩楼主描述的很清楚,举例很生动,也涉及了多核和多处理器的情况。本来也打算自己写一下的,看了楼主的文章就感觉没这个必要了。

    4. 翻译的不错,谢谢~

    5. 的确很有启发!
      谢谢分享那么生动的文章

    6. bluedavy bluedavy

      恩,这文章翻译的确是很不错,:),质量很高,必须顶!

    7. vvoody vvoody

      原来是这样,多谢翻译 ;-)

    8. sun_flow sun_flow

      例子很生动

    9. [...]IE6方程式[...]

    10. grep 'model name' /proc/cpuinfo
      model name : Intel(R) Xeon(R) CPU E5335 @ 2.00GHz
      model name : Intel(R) Xeon(R) CPU E5335 @ 2.00GHz
      model name : Intel(R) Xeon(R) CPU E5335 @ 2.00GHz
      model name : Intel(R) Xeon(R) CPU E5335 @ 2.00GHz

      没有wc参数看起来更有气势,嗷呜

    11. [...]看到上面的文字,“哦”一声,然后呢,估计过两天这个概念就忘了。《理解 Linux 的处理器负载均值(翻译)》做了一个详尽的解释。并最终给出了一个判断此值是否在合理范围内的一个法则:[...]

    12. [...]这个函数返回当前系统的负载均值信息(当然 Windows 下不适用),详细文档可以翻阅 PHP 的相关文档。文档中有段示例代码,基本上也就能看出它的用途了。[...]

    13. [...]转自:http://www.gracecode.com/archives/2973/[...]

    14. [...]  翻译原文来源:http://www.gracecode.com/archives/2973/[...]

    15. [...]说明:获取Linux负载均衡值信息,返回格式: array(1分钟, 5分钟, 15分钟)[...]

    16. [...]原文[...]

    17. [...]这个函数 返回当前系统的负载均值信息 (当然 Windows 下不适用),详细文档可以翻阅 PHP 的相关文档。文档中有段示例代码,基本上也就能看出它的用途了。[...]

    18. [...]这里有一篇文章,把load average说的很明白:http://www.gracecode.com/archives/2973/[...]

    19. Rex Rex

      终于搞明白了load average的含义了。呵呵

    20. [...]理解 Linux 的处理器负载均值(翻译)[...]

    21. [...]http://www.gracecode.com/archives/2973/[...]

     

     

    http://www.daniel-journey.com/archives/244

    《理解 Linux 的处理器负载均值》阅读笔记续

    2009年8月29日 admin 发表评论 阅读评论

    有位同事把《理解 Linux 的处理器负载均值(翻译)》群发给了公司的tech团队,同事们纷纷加以评论,下面是对其中经典内容的收集和整理,如果有同学看到下面的内容似曾相识的话,请不要奇怪:-)。

    • Google的工程师都知道, 如果Google面临同质竞争(导致upper line/广告收入的降低), Google最后的一个武器就是他们高效价廉的计算能力。Google自今年五月份以来公布关于其数据中心的技术细节, 其中包括他们高达80%的应用可以被GAE支持(动态部署), 免费冷却技术的大量使用, 极为优化的TPUE, 以及利用通用服务器(所以较为不易出现短板)来提高计算资源的平均利用率…..等项目, Google早已在2003年就开始有序地提高它的计算资源效率, 而这几个月公布的技术还是3-4年历史, 可见Google在计算资源效能的领先。
    • 如看到cpu iowait达到70-80%, 系统run的进程只有1-2个,而load达到几十或者上百。 这个明显是有资源堵塞了,比如磁盘啊,网络啊,增加再多的CPU资源也无效。再一个极端情况,我们看到系统load是1.x,机器有4个核,可程序设计的垃圾,单线程,它只吃一个核, 不加机器或者提高频率就无法解决。所以有时候单独看load,或者单独看cpu利用率都不能的得出准确的答案,系统优化
      和资源利用需要我们去持久的仔细分析。
    • iowait不能简单的理解就是磁盘IO,其他的如内存IO,网络IO都会涉及到iowait.就我们的系统而言,网络IO出现磁盘和网络,且用nas方式连接到存储的,很容易就出现高iowait,典型的代表就是image应用。
    • 还有合理的写磁盘,尽量使数据都压缩在同一block(操作系统)内,这需要对应用程序和操作系统同时做调整。
    • 根据实际经验,iowait 70%还能跑但挺吃力了,load高都是io等待引起的,有必要通过增加磁盘等途径降低io压力。
    • 多个磁盘并发操作来降低io等待时间。比如原来有两块盘来处理任务iowait很高,但是如果你增加到4块或6块盘并发操作,iowait是有一定的程度的下降的,具体下降多少还是要取决于io类型。转速是可以提高io速度,但是现在的单块普通硬盘极限值也就是170/s,oracle等数据库密集型io操作都是通过大量的磁盘来完成的。所以才会有热火朝天的ssd硬盘。
    • 对于磁盘来说,在转速一定的情况下,一块磁盘承受的IOPS是固定的,因为io wait主要在于磁头寻道的时间。所以简单点看IO wait,要不就增加磁盘数量(提高IOPS),要不就系统增加cache(减少IO),别无他法。
    • 对于CPU密集型的应用,可以很容易根据load值的大小决定是否需要增加CPU数量或者服务器数量。对于IO密集型的应用,如果系统load很高,cpu 利用率低,iowait非常高的话,建议修改程序架构(推荐,比如:引入cache机制等),或者升级存储设备(比如:利用SSD硬盘或者更高级别的存储)除了uptime外,top,  vmstat 等也是非常重要的系统性能诊断命令。
    • 应该更加关注应用的响应时间,注重通过性能优化等技术手段提升应用效率。加服务器虽然简单有效,但往往掩盖了软件本身的问题,而且潜在地造成了浪费。
    • 很多WEB类应用是不能充分利用系统资源的。所以会推行虚拟机,也就是在一台物理机上跑多个虚拟机,比较适合于对网络和DISK IO要求不太高的应用。

     

    评论
    添加红包

    请填写红包祝福语或标题

    红包个数最小为10个

    红包金额最低5元

    当前余额3.43前往充值 >
    需支付:10.00
    成就一亿技术人!
    领取后你会自动成为博主和红包主的粉丝 规则
    hope_wisdom
    发出的红包
    实付
    使用余额支付
    点击重新获取
    扫码支付
    钱包余额 0

    抵扣说明:

    1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
    2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

    余额充值