译文，原文:Understanding Linux CPU Load – when should you be worried? 参考理解 Linux 的处理器负载均值(by 明城)。如下是正文内容。
你可能对于 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 的话情况就更不妙了，除了桥上的车外，有超出桥负载两倍多的车辆正在等待。依次类推。
上面的情况和CPU的负载情况非常相似。汽车代表使用CPU时间片（正在大桥上通行）或者等待使用CPU（排队）的进程。Unix 系统定义的执行队列长度是：运行中的进程数+队列中等待运行的进程数。
和收过桥费的管理员一样，你当然希望你的汽车（进程）不用焦急地等待。所以，理想状态 下，都希望CPU负载小于 1.00 。当然不排除部分峰值会超过 1.00。当时如果长期超过1.00，你就应该重视这个问题来！
所以你的理想负荷为 1.00 ？
这并不确切。负荷 1.00 说明系统已经没有剩余的资源了。在实际情况中 ，有经验的系统管理员都会将这条线划在 0.70，这样大致有如下三个规则：
需要进行调查（0.70）: 如果你的系统负载保持在 0.7以上，那么你需要在事情变得更糟糕之前，花些时间了解其原因。现在就要修复（1.00）: 如果你的服务器系统负载长期超过 1.00，那么就应该马上解决这个问题。否则，你将半夜接到你上司的电话，这可不是件令人愉快的事情。凌晨三点的哀嚎（5.00）: 如果你的服务器负载超过了 5.00 这个数字，那么你摊上大事了，你的服务器可能无法响应或者明显变慢，更要命的是这往往发生在最不适当的时候，例如凌晨三点，或者开会途中。千万不要让它发生。那么多个处理器呢？我的均值是 3.00，但是系统运行正常！
哇喔，你有四个处理器的主机？那么它的负载均值在 3.00 是很正常的。
在多处理器(multi-processor)系统中，负载均值是基于处理器核心(processor core)的数量决定的。在不同处理器核心(core)数量的服务器上，CPU 100%利用率的数值表示并不一样，1.00 表示单个核心(single-core)负载满，而 2.00 则两个处理器核心(dual-core)负载满，那么 4.00 就有四个核心(quad-core)。
回到我们上面有关车辆过桥的比喻。1.00 的负载表示单车道桥梁已经被车塞满了。而双车道的大桥，意味着多出了一倍的 负载，也就是说还有 50% 的剩余系统资源 — 因为还有另外条车道可以通行。
CPU的道理一样，1.00表示单CPU已经100%使用率，而2.00表示双CPU核心到达100%使用率。
多核(multicore)与多处理器(multiprocessor)
先脱离下主题，我们来讨论下多核(multicore)与多处理器(multiprocessor)的区别。从性能的角度上理解，一台拥有单个处理器processor（含两个核心core）的主机与另一台拥有两个处理器processor（各含一个核心core），两者基本差不多吗？ 基本可以这么理解，相差无几。当然实际情况会复杂得多，不同数量的缓存、处理器的频率等因素都可能造成性能的差异。我们排除这些点上的干扰，从计算CPU负载的角度，还是处理器核心core的总数最重要，也不需要关注这些core是如何分布在不同的processor上。
由此，我们引出两条新的规则：
处理器核心core数量=最大负载load: 在multicore的系统中，你们的压力不会超过core数量；处理器核心core才是核心关注点: 不需要关注core如何分布在不同处理器上，只看数量！所以，从Load的角度，两个四核心的处理器==四个双核心的处理器==8个单独的核心，总共8个处理器核心。
Bring It Home
让我们再来看看 uptime 输出的负载信息
~ $ uptime23: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，那么仍可以说明认定服务器情况还是正常的，因为有偶发因素。 但是如果十五分钟的数值仍然保持高于 1.00，那么就值得注意了。注意，这里的1.00针对单核心，根据你拥有的核心数来设置判定的阈值。
哦，处理器核心的数量在解读系统负载时很重要，那么我如何得知我的系统有多少颗处理器核心core呢？
在 Linux 下，可以使用
cat /proc/cpuinfo
获取你系统上的每个处理器的信息。如果你只想得到数字，那么就使用下面的命令：
grep 'model name' /proc/cpuinfo | wc -l
推荐者说：本文用形象的比喻，用通俗的语言解释来Linux下load的含义，其与处理器核心（core）的关系，以及我们何时对load指标应该引起注意。
The post 理解 Linux 的CPU Load负载-何时该引起重视了？ appeared first on SQLParty.
