本文字数：2098字
阅读时间：7分钟
对于理解Linux系统运行状态，尤其是当前和最近一段时间的状态，CPU平均负载值都是一个非常重要的指标。很多情况下“平均负载”这个术语会跟CPU使用率百分比混淆，但实际上它们的区别很大。本文我将试着解释这两个指标的真实含义，以及讲解如何判断Linux系统是否过载或者未充分使用的。
平均负载
在不同的监控工具里(top，atop，htop等等)，平均负载被展示为一个三值集，分别表示在过去的1、5和15分钟里被观测的Linux系统经历的平均CPU负载。所以，第一个不同点是这些值都是历史值，而CPU使用率百分比通常在1到5秒的间隔内采集计算得到的，所以可以近似认为这个值是实时的。
CPU负载表示了Linux那些处于就绪、runnable状态、更重要的是不可中断睡眠状态(uninterruptible睡眠状态)的平均任务数(读取一组对应于进程执行线程的机器语言任务指令)。这也就是说，为了计算CPU负载的值，只考虑那些处于running状态，或者等待分配CPU时间的进程。一般睡眠状态的进程、僵尸进程和停止状态的进程不予考虑。
进程状态码：
R：running或者可运行状态(在就绪队列里)
D：不可中断睡眠状态(通常在执行IO)
S：可中断睡眠状态(等待事件完成)
Z：defunct/僵尸进程，执行终止但未被父进程清理
T：停止状态，可能被任务控制或者因为被追踪(traced)
下面是在单核处理器上不同负载值所表示的含义：
0.00：没有任何正在运行的进程或者等待被CPU执行的进程，即CPU完全空闲。这样一来，如果一个运行的程序需要执行某个任务，它可以立刻从操作系统请求CPU并分配一定的CPU时间来执行这个任务，因为没有其他进程竞争CPU。
0.50：没有任何等待执行的进程，CPU正在处理之前的进程，并且占用了50%的处理能力。在这种情况下，操作系统仍然能够立即分配CPU时间给其他进程而无需等待。
1.00：就绪队列里没有任务，但是CPU使用了100%的处理能力来处理之前的进程。所以如果有新的进程请求CPU时间，那么就需要等待直到另一个进程完成执行，或者当前的CPU时间(CPU tick)过期，由操作系统选择下一个要执行的进程。
1.50：CPU使用100%的处理能力，并且15个任务中只有5个请求CPU时间，即33.33%的任务需要排队等待其他任务耗尽它们的CPU时间。所以一旦超过了1.0的阈值，就可以说这个系统已经处于过载状态，因为它不能立即处理所有任务的请求。
多处理器和多核系统
多处理器或多核(多个逻辑的CPU)系统，意味着CPU负载值依据系统中处理器的数量而变化。这样，一台四核处理器除非它的负载为4.00时才会达到100%的使用率。所以你在面对top，htop或者uptime显示的CPU三个负载值的时候，需要做的第一件事情是除以你的系统中逻辑CPU的数量，然后再从中得出结论。
CPU使用率百分比
如果我们观察一段时间里经过CPU处理的不同进程，使用率百分比表示CPU执行每个进程指令花费的时间与这段时间的比值。但是这个计算仅限于处于running状态的进程，不包括那些处于等待状态的进程，不管它们是在就绪队列里(runnable state)还是不可中断睡眠状态(等待IO操作完毕)的都不予考虑。
所以CPU使用率百分比这个指标启发我们哪个进程“压榨”CPU最厉害，但是不能为我们描绘系统状态是过载还是未完全使用的真实图景。
考虑IO操作
我在这篇文章开头强调了不可中断睡眠状态(上面状态图中D状态)的重要性，这是因为有时你可以发现系统中巨高无比的负载值，但是不同的运行进程都只有一个相对较低的使用率百分比。如果你不了解这个状态的话，你很难解释这个现象，也不知道该如何解决它。对于一个处于这种状态的进程，它可能在等待某些资源释放，并且它的执行无法被中断，例如它在等待一些不可中断的IO操作(不是所有都不可中断)。典型的场景是磁盘故障，像NFS这样的网络文件系统故障，或者使用了非常低速的设备，比如USB 1.0等。
在这个场景里，我们需要使用一些别的工具，比如iostat或者iotop来检查进程是否执行庞大的IO操作，然后我们通过杀死这些进程或者给它们分配较低优先级(nice命令)来给其它更加关键的任务分配更多CPU的效果。
一些建议
系统过载并且负载值超过1.0有时候不算什么问题，因为即使有些延迟，CPU依然会处理到队列里的任务，这时负载就会降低到1.0以下的值。但是如果系统负载值持续超过1那就意味着它不能吸收执行中所有的负载，所以它的响应时间会增加，并且系统开始变慢，无法及时响应。高于1的负载值，尤其是过去5分钟和15分钟的平均负载值，对于我们需要提升系统硬件，通过限制用户使用以请求更少资源，或者在多个相似节点间分摊负载等来说，都是一个清晰的信号。
这样的话，我列出一些推荐的操作：
= 0.70：无事发生，但是需要监测CPU负载。如果一直持续，就有必要在事情严重之前调查一下原因。
= 1.00：发生了某些问题，你需要找出它并且修复。否则当系统遇到负载增长会导致你的应用响应变慢甚至无响应。
= 3.00：你的系统正在变得极慢。很难通过命令行操作并找到问题原因。所以需要花费比我们之前更长的时间来修复这个问题。你的操作冒着增加系统饱和度甚至宕机的风险。
= 5.00：你很可能已经无法恢复系统。你要等到负载大幅降低的奇迹发生，或者你对发生的事情有想法并且能够承受对应的后果，你可以在控制台使用命令pkill -9 并且祈祷可以它可以被执行来缓解系统负载，增加更多控制希望。否则你可能只有重启你的计算机了。
文末福利
容器时代又来给大家送福利啦！这次我们为大家带来了又一本好书——《Redis 使用手册》。想要获得这本书吗？点击左下角“
往期推荐
在kubeadm中使用pod安全策略
在K8s上使用具有Vault的Spring Boot
应用程序安全性和准确性不能被移交给Istio或任何服务网格
如何在K8s中使用Envoy作为负载均衡器
Windows Server 2019上的Docker 入门
本文英文原文：
http://www.daniloaz.com/en/what-is-the-true-meaning-of-system-average-load-and-cpu-utilization-in-linux/
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
