理解Linux 的处理器负载均值

阅读更多

Linux负载均值到底是什么意思？ 这个数值究竟如何说明服务器是忙是闲？依据这个数值来决定是否需要添加服务器，靠谱么？在网上google了一篇文章描述的非常形象，当然也通俗易懂喔。可以收藏喔

你可能对于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

 

内核如何计算负载：

对于linux来说，采样计算load时间间隔为5秒，这都是在source code里面定义的固定数字，其采样结构通过动态内存文件系统 /proc/loadavg 可以动态的得到适时数据，其他工具的输出，比如 uptime / top/sar 等都是读该内存数据所产生的。我们在这里主要考究kernel的算法。 

对于5秒的间隔，是动态地采样cpu状态数据，也就是run queue size ，这包括正在cpu中running的进程数量以及在cpu等待队列里面的进程数量。对于linux来说，实际上会计算1分钟、5分钟、15分钟的移动平均。为此首先我们要介绍linux 里面定义的3个常量： 

#define EXP_1 1884 /* 1/exp(5sec/1min) */ 
#define EXP_5 2014 /* 1/exp(5sec/5min) */ 
#define EXP_15 2037 /* 1/exp(5sec/15min) */ 

三个常量分别表示1/5/15分钟的常量，计算方法是： 

1884 = 2048/(power(e,(5/(60*1)))) /* e = 2.71828 */ 

2014 = 2048/(power(e,(5/(60*5)))) 

2037 = 2048/(power(e,(5/(60*15)))) 

我们假定前一时刻按常量1884计算的load为 load1(t-1),当前采样run queue size 为 rq1,则当前load1(t) = ((load1(t-1) * 1884) + rq1 * (2048 - 1884))/2048 

同理可以5分钟和15分钟移动平均的算法分别为 load5(t) = ((load5(t-1) * 2014) + rq1 * (2048 - 2014))/2048和load_15(t) = ((load15(t-1) * 2037) + rq1 * (2048 - 2037))/2048 

由此可以看出，移动平均间隔越大，当前run queue size 对移动平均的影响趋向减小。 

至于为什么取这个数，涉及到微积分方面的知识了，这样做出的图象更平滑。