uptime
dyy@dyy-Lenovo-ThinkBook-14-IIL:~$ uptime
10:27:10 up 7 min, 1 user, load average: 1.32, 0.99, 0.49
结果分别对应：当前时间、系统运行时间、当前用户数目、过去 1 分钟、5 分钟、15 分钟的平均负载(Load
Average)
平均负载是指单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数，和 CPU使用率没有直接关系。
可运行状态进程：正在使用CPU或者正在等待CPU的进程；即ps命令看到的，处于R状态的进程
不可中断状态进程：正处于内核态关键流程中的进程，并且这些流程是不可打断的，比如等待硬件设备的I/O响应，即ps命令中看到的D状态的进程。
不可中断状态实际上是系统对进程和硬件设备的一种保护机制。
下面语句可以得到CPU个数，一般来说，平均负载大于CPU的0.7倍时就需要注意了，大于CPU个数的话就会出现过载。
grep 'model name' /proc/cpuinfo | wc -l
8
通过对于平均负载的定义可以看出，它不仅包括了正在使用CPU的进程，还包括等待CPU和等待IO的进程。
CPU使用率与平均负载的关系：
CPU密集型进程，使用大量CPU会导致平均负载升高，两者一致。
I/O密集型进程，等待I/O也会导致平均负载升高，但CPU使用率不一定很高。
大量等待CPU的进程调度也会导致平均负载升高，此时的CPU使用率也会比较高。
接下来是实测：
CPU 密集型进程
stress 是一个 Linux 系统压力测试工具，我们在终端1运行该工具。
在终端2，不断运行uptime，可以发现平均负载在不断上升。
mpstat 是一个常用的多核 CPU 性能分析工具,用来实时查看每个 CPU 的性能指标,以
及所有 CPU 的平均指标，我们在终端3运行它。可以发现有一个核的使用率为100%，但是iowait为0.
通过运行# pidstat -u 5 1，可以看到是运行stress的进程占用率为100%
IO密集型进程
stress 命令,但这次模拟 I/O 压力,即不停地执行 sync，下面是显示效果，可以发现iowait很高，导致了平均负载很高。
大量进程场景
由于机子有8个核，我开12个进程用作运行stress，这样CPU处于过载状态，10.92明显是比8大的，再用pidstat可以看出
个进程等待 CPU 的时间(也就是代码块中的%wait 列)高达 60~75%，这里就是上图的倒数第二列显示。