1.通过我们在查看当前系统的状态的时候，往往会采用top或者uptime命令进行查看。
[root@node01 ~]# uptime 06:17:15 up 28 min, 3 users, load average: 0.00, 0.01, 0.04
其中后面的三个数字表示：过去的1分钟、5分钟、15分钟内的平均负载。这三个不同时间间隔的平均值，其实给我们提供了，分析系统负载趋势的数据来源，让我们能更全面，更立体地理解目前的负载状态。
比如说：在一个单cpu系统中看到的平均负载为1.73、0.60、7.98，那么说明在过去的1分钟内，系统有73%的超载，在过去的15分钟内，有698%的超载，因而从整体趋势来看，系统的负载在降低。
平均负载：指的是单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是是平均活跃进程数。
它和cpu的使用率没有直接的关系。
可运行状态的进程，是指正在使用cpu或着正在等待cpu的进程，也就是我们常用ps命令看到的，出入R状态(Ruing)或者(Runnable)的进程。
不可中断状态：指的是正在处于内核态关键流程中的进程，并且这些流程都是不可中断的，比如说最常见的是等待硬件设备I/O响应，也就是我们在ps命令中看到的D状态(Uninterruptible sleep,也称为Disk sleep)的进程。比如：当一个进程想磁盘读写数据时，为了保证数据的一致性，在得到磁盘回复前，它是不能被其他进程或这中断打断的，这个时候的进程处于不可中断状态，如果此时的进程被打断了，就容易出现磁盘数据与进程数据不一致的问题。所以，不可中断状态实际上是系统对进程和硬件设备的一种保护机制。
查看系统cpu的命令
[root@node01 ~]# grep 'model name' /proc/cpuinfo|wc -l 1
2.平均负载与CPU使用率
平均负载是指单位时间内，处于可运行状态和不可中断状态的进程数，所以它不仅包括了正在使用cpu的进程，还包括等待cpu和等待i/o的进程
而cpu使用率，是单位时间内cpu繁忙情况的统计，跟平均负载并不一定完全对应。
- CPU 密集型进程，使用大量 CPU 会导致平均负载升高，此时这两者是一致的；
- I/O 密集型进程，等待 I/O 也会导致平均负载升高，但 CPU 使用率不一定很高；
- 大量等待 CPU 的进程调度也会导致平均负载升高，此时的 CPU 使用率也会比较高。
工具： iostat、mpstat、pidstat
安装：
yum -y install stress sysstat
stress 是一个 Linux 系统压力测试工具，这里我们用作异常进程模拟平均负载升高的场景
而 sysstat 包含了常用的 Linux 性能工具，用来监控和分析系统的性能。我们的案例会用到这个包的两个命令 mpstat 和 pidstat。
1.mpstat 是一个常用的多核 CPU 性能分析工具，用来实时查看每个 CPU 的性能指标，以及所有 CPU 的平均指标。
2.pidstat 是一个常用的进程性能分析工具，用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标
场景1：cpu密集型
这里预先开启三个回话窗口
session1 : 终端运行 stress 命令，模拟一个 CPU 使用率 100% 的场景
$ stress --cpu 1 --timeout 600
session2:在第二个终端运行 uptime 查看平均负载的变化情况
# -d 参数表示高亮显示变化的区域 $ watch -d uptime ..., load average: 1.00, 0.75, 0.39
session3:运行 mpstat 查看 CPU 使用率的变化情况：
# -P ALL 表示监控所有CPU，后面数字5表示间隔5秒后输出一组数据 [root@node01 ~]# mpstat -P ALL 5 Linux 3.10.0-1160.24.1.el7.x86_64 (node01) 06/10/2021 _x86_64_ (1 CPU) 06:53:46 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 06:53:51 AM all 99.80 0.00 0.20 0.00 0.00 0.00 0.00 0.00 0.00 0.00 06:53:51 AM 0 99.80 0.00 0.20 0.00 0.00 0.00 0.00 0.00 0.00 0.00
session4:到底是哪个进程导致了 CPU 使用率为 100% 呢？你可以使用 pidstat 来查询
[root@node01 ~]# pidstat -u 5 1 ##显示所有CPU的指标，并在间隔5秒输出一组数据 Linux 3.10.0-1160.24.1.el7.x86_64 (node01) 06/10/2021 _x86_64_ (1 CPU) 06:57:06 AM UID PID %usr %system %guest %CPU CPU Command 06:57:11 AM 0 42 0.00 0.20 0.00 0.20 0 kworker/u256:1 06:57:11 AM 0 2211 98.41 0.20 0.00 98.61 0 stress 06:57:11 AM 0 2218 0.20 0.20 0.00 0.40 0 watch 06:57:11 AM 0 2238 0.00 0.20 0.00 0.20 0 pidstat
从这里可以明显看到，stress 进程的 CPU 使用率为 100%。
场景二：I/O密集型
session1:运行 stress 命令，但这次模拟 I/O 压力，即不停地执行 sync：
$ stress -i 1 --timeout 600
session2:运行 uptime 查看平均负载的变化情况：
$ watch -d uptime
session3:第三个终端运行 mpstat 查看 CPU 使用率的变化情况：
mpstat -P ALL 5 1
session4；到底是哪个进程导致了 CPU 使用率为 100% 呢？你可以使用 pidstat 来查询
[root@node01 ~]# pidstat -u 5 1 Linux 3.10.0-1160.24.1.el7.x86_64 (node01) 06/10/2021 _x86_64_ (1 CPU) 07:06:42 AM UID PID %usr %system %guest %CPU CPU Command 07:06:47 AM 0 42 0.00 8.33 0.00 8.33 0 kworker/u256:1 07:06:47 AM 0 2338 3.57 78.77 0.00 82.34 0 stress 07:06:47 AM 0 2339 0.20 0.20 0.00 0.40 0 watch 07:06:47 AM 0 2418 0.00 8.13 0.00 8.13 0 kworker/u256:0 07:06:47 AM 0 2523 0.00 0.20 0.00 0.20 0 pidstat
场景3：大量进程场景
当系统中运行进程超出 CPU 运行能力时，就会出现等待 CPU 的进程。
比如，我们还是使用 stress，但这次模拟的是 8 个进程：
session1:
$ stress -c 8 --timeout 600
session2:由于系统只有 21个 CPU，明显比 8 个进程要少得多，因而，系统的 CPU 处于严重过载状态，平均负载高达 7.97：
$ uptime ..., load average: 7.97, 5.93, 3.02
session3:
[root@node01 ~]# mpstat -P ALL 5 1 Linux 3.10.0-1160.24.1.el7.x86_64 (node01) 06/10/2021 _x86_64_ (1 CPU) 07:15:26 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 07:15:31 AM all 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 07:15:31 AM 0 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
session4:
[root@node01 ~]# pidstat -u 5 1 Linux 3.10.0-1160.24.1.el7.x86_64 (node01) 06/10/2021 _x86_64_ (1 CPU) 07:14:37 AM UID PID %usr %system %guest %CPU CPU Command 07:14:42 AM 0 2581 12.18 0.00 0.00 12.18 0 stress 07:14:42 AM 0 2582 12.38 0.00 0.00 12.38 0 stress 07:14:42 AM 0 2583 12.38 0.00 0.00 12.38 0 stress 07:14:42 AM 0 2584 11.98 0.00 0.00 11.98 0 stress 07:14:42 AM 0 2585 11.98 0.00 0.00 11.98 0 stress 07:14:42 AM 0 2586 12.18 0.00 0.00 12.18 0 stress 07:14:42 AM 0 2587 12.18 0.00 0.00 12.18 0 stress 07:14:42 AM 0 2588 12.18 0.00 0.00 12.18 0 stress 07:14:42 AM 0 2589 0.00 0.20 0.00 0.20 0 watch Average: UID PID %usr %system %guest %CPU CPU Command Average: 0 2581 12.18 0.00 0.00 12.18 - stress Average: 0 2582 12.38 0.00 0.00 12.38 - stress Average: 0 2583 12.38 0.00 0.00 12.38 - stress Average: 0 2584 11.98 0.00 0.00 11.98 - stress Average: 0 2585 11.98 0.00 0.00 11.98 - stress Average: 0 2586 12.18 0.00 0.00 12.18 - stress Average: 0 2587 12.18 0.00 0.00 12.18 - stress Average: 0 2588 12.18 0.00 0.00 12.18 - stress Average: 0 2589 0.00 0.20 0.00 0.20 - watch
可以看出，8 个进程在争抢 1 个 CPU，每个进程等待 CPU 的时间（也就是代码块中的 %wait 列）高达 75%。这些超出 CPU 计算能力的进程，最终导致 CPU 过载。