CPU 使用率和负载Load_cpu load

优质博文：

一、CPU 使用率

CPU 使用率是 CPU 处理非空闲任务所花费的时间百分比 。例如单核 CPU 1s 内非空闲态运行时间为 0.8s ，那么它的 CPU 使用率就是 80% ；双核 CPU 1s 内非空闲态运行时间分别为 0.4s 和 0.6s ，那么，总体 CPU 使用率就是 (0.4s + 0.6s) / (1s * 2) = 50% ，其中 2 表示 CPU 核数，多核 CPU 同理。 CPU 使用率只能在指定的时间间隔内测量。我们可以通过将空闲时间的百分比从 100 中减去来确定 CPU 使用率。

在 Linux 中，进程分为三种状态，一种是阻塞的进程 blocked process ，一种是可运行的进程 runnable process ，另外就是正在运行的进程 running process 。

使用率这个要结合时间片来说，从上图的演变可以看出影响使用率高低的因素不是 load 的多少，而是在分配给某个进程时间片时，这个进程是否使用了 CPU 的计算能力。在第四分钟时候，分配给蓝人 1 分钟，但是它什么也没干，这 1 分钟内电话是闲置的没有被使用，所以这一分钟内的电话使用率就是 0% 。但是 load 是 3 。

当然这里就存在一个统计周期的问题，上图我们的统计周期是 1 分钟，而分配给每个人的最小时间单位也是 1 分钟。从计算机角度来说，单核心 CPU ，假设 1 秒钟分为 100 个时间片，如果 2 个任务，第一个任务用了 5 个时间片执行完成，另外一个任务用了 15 个时间片执行完成，所以如果统计周期是 1 秒，那么这 1 秒内的 CPU 使用率就是 20% 。 CPU 利用率高不一定负载高， CPU 利用率是一段时间内 CPU 被占用的情况。

二、CPU Load

CPU 负载定义为 在单个时间点使用或等待使用一个内核的进程数 。在单核系统，我们的 CPU 平均负载始终低于 0.7 。这表明每个需要使用 CPU 的进程都可以立即使用它，而无需等待。如果 CPU 平均负载大于 1 ，则表示有进程需要使用 CPU ，但由于 CPU 不可用，目前无法使用。在多处理器系统中高于 1 的平均负载不会成为问题，因为有更多内核可用。

上图的电话亭可以理解为一个 CPU 核心。从上图的过程中可以看到 load 的概念，而使用率始终 100% 。

理想的 CPU load 是多少：这个跟你的 CPU 核心数量有关，理想情况下一个核心被一个进程占用，如果你是 4 个核心，那么跑 4 个进程，此时 Load 是 4 但是也不高，如果你只有 2 个核心，依然跑 4 个进程，这就意味着有一半进程在某一个时刻抢不到 CPU ，这时候 Load 还是 4 ，如果是短期状态还无所谓，如果长期是这个状态你就要注意了。

一般来说只要每个 CPU 的当前活动进程数不大于 3 那么系统的性能就是良好的，如果每个 CPU 的任务数大于 5 ，那么就表示这台机器的性能有严重问题。

三、CPU 使用率和负载常用命令

top 命令查看 CPU 使用率

通常， top 命令通常用于显示系统上的活动进程以及这些进程消耗了多少资源。不过，我们可以使用这个命令来测量 CPU 的状态：

[root@localhost ~]# top
top -07:08:31 up  2:41,1 user,  load average:1.09,1.11,1.30
Tasks:322 total,2 running,320 sleeping,0 stopped,0 zombie
%Cpu(s):10.0 us,15.0 sy,0.0 ni,97.8 id,0.0 wa,5.0 hi,0.0 si,0.0 st
MiB Mem :3709.4 total,1483.1 free,1402.0 used,824.4 buff/cache
MiB Swap:2048.0 total,2048.0 free,0.0 used.2053.4 avail Mem 

参数说明：
【1】 us(user) ：表示 CPU 在用户态运行的时间百分比，通常用户态 CPU 高表示有应用程序比较繁忙。典型的用户态程序包括：数据库、 Web 服务器等；
【2】 sy(sys) ：表示 CPU 在内核态运行的时间百分比（不包括中断），通常内核态 CPU 越低越好，否则表示系统存在某些瓶颈；
【3】 ni(nice) ：表示用 nice 修正进程优先级的用户态进程执行的 CPU 时间。 nice 是一个进程优先级的修正值，如果进程通过它修改了优先级，则会单独统计 CPU 开销；
【4】 id(idle) ：表示 CPU 处于空闲态的时间占比，此时， CPU 会执行一个特定的虚拟进程，名为 System Idle Process 空闲时间；
【5】 wa(iowait) ：表示 CPU 在等待 I/O 操作完成所花费的时间，通常该指标越低越好，否则表示 I/O 存在瓶颈，可以用 iostat 等命令做进一步分析；
【6】 hi(hardirq) ：表示 CPU 处理硬中断所花费的时间。硬中断是由外设硬件（如键盘控制器、硬件传感器等）发出的，需要有中断控制器参与，特点是快速执行；
【7】 si(softirq) ：表示 CPU 处理软中断所花费的时间。软中断是由软件程序（如网络收发、定时调度等）发出的中断信号，特点是延迟执行；
【8】 st(steal) ：表示 CPU 被其他虚拟机占用的时间，仅出现在多虚拟机场景。如果该指标过高，可以检查下宿主机或其他虚拟机是否异常；
【9】 load average ：表示 CPU 的平均负载，这 3 个数字分别表示 1 分钟、 5 分钟、 15 分钟内系统的平均负载。该值越小，表示系统工作量越少，负荷越低；反之负荷越高；

平均负载 Load Average ：指单位时间内，系统处于 可运行状态（Running / Runnable）和不可中断态 的平均进程数，也就是 平均活跃进程数 。

可运行态进程包括正在使用 CPU 或者等待 CPU 的进程；不可中断态进程是指处于内核态关键流程中的进程，并且该流程不可被打断。比如当进程向磁盘写数据时，如果被打断，就可能出现磁盘数据与进程数据不一致。不可中断态，本质上是系统对进程和硬件设备的一种保护机制。

理想情况下，每个 CPU 应该满负荷工作，并且没有等待进程，此时，平均负载 = CPU 逻辑核数。但是，在实际生产系统中，不建议系统满负荷运行。通用的经验法则是：平均负载 = 0.7 * CPU 逻辑核数。
1、当平均负载持续大于 0.7 * CPU 逻辑核数，就需要开始调查原因，防止系统恶化；
2、当平均负载持续大于 1.0 * CPU 逻辑核数，必须寻找解决办法，降低平均负载；
3、当平均负载持续大于 5.0 * CPU 逻辑核数，表明系统已出现严重问题，长时间未响应，或者接近死机。

除了关注平均负载值本身，也应关注平均负载的变化趋势，这包含两层含义。一是 load1 、 load5 、 load15 之间的变化趋势；二是历史的变化趋势。
1、当 load1 、 load5 、 load15 三个值非常接近，表明短期内系统负载比较平稳。此时，应该将其与昨天或上周同时段的历史负载进行比对，观察是否有显著上升。
2、当 load1 远小于 load5 或 load15 时，表明系统最近 1 分钟的负载在降低，而过去 5 分钟或 15 分钟的平均负载却很高。
3、当 load1 远大于 load5 或 load15 时，表明系统负载在急剧升高，如果不是临时性抖动，而是持续升高，特别是当 load5 都已超过 0.7 * CPU 逻辑核数时，应调查原因，降低系统负载。

如果 1 个 CPU 的系统平均负载= 1.7 ：如果 CPU 每分钟最多处理 100 个进程，意味着除了 CPU 正在处理的 100 个进程以外，还有 70 个进程正排队等着 CPU 处理。 2 个 CPU 表明系统负荷可以达到 2.0 。

此外，需要注意的是， top 命令显示了单个内核的 CPU 百分比。在多处理器系统中， CPU 百分比可能超过 100% 。例如，如果 4 个核心为 75% ， top 命令将显示 CPU 为 300% 。由于 CPU 有多种非空闲态，因此， CPU 使用率计算公式可以总结为： CPU 使用率 = (1 - 空闲态运行时间/总运行时间) * 100%。根据经验法则， 建议生产系统的 CPU 总使用率不要超过 70% 。

我们需要获取空闲时间的值，以便我们可以从 100 中减去它来获得使用情况：

[root@localhost ~]# top -bn2 | grep '%Cpu'| tail -1| grep -P '(....|...) id,'|awk '{print "CPU Usage: " 100-$8 "%"}'
CPU Usage:2.2%

-n 选项是 top 命令在结束前应该使用的迭代次数。我们避免使用第一个循环，因为我们检索的指标将是自启动以来的值。因此，我们进行了第二次迭代。或者，在多处理器系统中，我们必须将给定的 id 值除以内核数，然后从 100 中减去该值。例如，如果我们在四核系统上运行，并且 id 值为 304% ，我们将 CPU 使用率计算为：

CPU 使用率 %=100 – (304/4)[root@localhost ~]# top -bn2 | grep '%Cpu'| tail -1| grep -P '(....|...) id,'|awk '{print "CPU Usage: "100-($8/4)"%"}'

vmstat 命令查看 CPU 的使用率

[root@localhost ~]# vmstat 34
procs -----------memory-------------swap-------io-----system--------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 4001347080612094146400681172137129700100134708061209414640000841571297001001347080612094146400005910711980010013470806120941464000159104119800

id 列是我们感兴趣的。延迟一秒，我们使用 vmstat 计算 CPU 使用率：

[root@localhost ~]# echo "CPU Usage: "$[100-$(vmstat 12|tail -1|awk '{print $15}')]"%"
CPU Usage:2%

没有提供任何参数的 vmstat 命令将给出自引导以来的 CPU 时间。这不会提供准确的 CPU 使用百分比。因此，参数只能是 1 和 2 ，我们采用一秒钟后计算的指标：

vmstat 12

/proc/stat 命令查看 CPU 使用率

CPU 活动也可以从 /proc/stat 文件中提取。该文件包含自启动以来有关系统的各种指标：

[root@localhost~]# cat /proc/stat 
cpu  3020281863224043543247000
cpu0 3020281863224043543247000
intr 964682810000000010001263000369601539280000000000000000000000000000000000002070411460000000000000000343970000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
ctxt 340950
btime 1628404433
processes 3276
procs_running 2
procs_blocked 0
softirq 1128671168575626951002610094913

第一行， cpu 是系统所有核心指标的聚合。在具有 4 个内核的系统上，将有 4 条 cpu 线—— cpu0 、 cpu1 、 cpu2 和 cpu3 。 cpu 行中的列表示处理不同任务所花费的时间：
【1】 user 在用户模式下花费的时间；
【2】 nice 在用户模式下处理 nice 进程所花费的时间；
【3】 system 执行内核代码所花费的时间；
【4】 idl 空闲时间；
【5】 iowait 等待 I/O 所花费的时间；
【6】 irq 服务中断所花费的时间；
【7】 softirq 服务软件中断所花费的时间；
【8】 steal 从虚拟机中窃取的时间；
【9】 guest 为来宾操作系统运行虚拟 CPU 所花费的时间；
【10】 guest_nice 为“不错的”客户操作系统运行虚拟 CPU 所花费的时间；
我们将使用这些指标来计算平均空闲百分比。随后，我们将使用计算值来计算 CPU 使用率。需要注意的是，较旧的 Linux 发行版不计算窃取、来宾或来宾 _nice 指标。如果我们使用的是旧系统，我们会在计算中忽略这些指标：

平均空闲时间 (%)=(idle *100)/(user + nice + system + idle + iowait + irq + softirq +steal + guest + guest_nice)
​
cat /proc/stat |grep cpu |tail -1|awk '{print($5*100)/($2+$3+$4+$5+$6+$7+$8+$9+$10)}'|awk '{print "CPU Usage: "100-$1}'
CPU Usage:2.4219

由于我们正在开发单核系统，因此 cpu 行将与 cpu1 相同。因此， tail -1 的使用是 只检索其中一行。然而，我们会在多处理器系统上使用 cpu 行，因为它是所有内核上的指标的集合。

uptime 查看平均负载

uptime 命令为我们提供了以 1、5 和 15 分钟为间隔的平均负载视图：

[root@localhost ~]# uptime
 12:40:05 up  2:29,1 user,  load average:0.37,0.08,0.03

如果不知道系统的核心数，就无法解释平均负载：

[root@localhost ~]# cat /proc/cpuinfo |grep core
core id      :0
cpu cores    :2

四、总结

CPU 利用率低负载高： 说明等待执行的任务很多，但是通常任务多 CPU 使用率也会比较高，如果低就说明 CPU 根本没工作，那些很多的任务处于等待状态，可能进程僵死了。
CPU 利用率高负载低： 说明任务少，但是任务执行时间长，有可能是程序本身有问题，如果没有问题那么计算完成后则利用率会下降。

CPU 使用率与平均负载的关系： CPU 使用率是单位时间内 CPU 繁忙程度的统计。平均负载不仅包括正在使用 CPU 的进程，还包括等待 CPU 或 I/O 的进程。因此，两者不能等同，有两种常见的场景如下所述：
【1】 CPU 密集型应用，大量进程在等待或使用 CPU ，此时 CPU 使用率与平均负载呈正相关状态。
【2】 I/O 密集型应用，大量进程在等待 I/O ，此时平均负载会升高，但 CPU 使用率不一定很高。

生产 CPU 使用率低而平均负载高的场景： 等待磁盘 I/O 完成的进程过多，队列长度大，导致负载高，但此时 CPU 被分配执行别的任务或空闲，具体如：
【1】 磁盘读写请求过多导致大量 I/O 等待： CPU 的工作效率要高于磁盘，而进程在 CPU 上面运行需要访问磁盘文件，这个时候 CPU 会向内核发起调用文件的请求，让内核去磁盘取文件，这个时候会切换到其他进程或者空闲，这个任务就会转换为不可中断睡眠状态。当这种读写请求过多就会导致不可中断睡眠状态的进程过多，从而导致负载高， CPU 低的情况。
【2】 数据库抖动： 造成线程队列 hang 住，负载升高。
【3】 外接硬盘故障： 常见有挂了 NFS ，但是 NFS server 故障了。比如系统挂载了外接硬盘如 NFS 共享存储，经常会有大量的读写请求去访问 NFS 存储的文件，如果这个时候 NFS Server 故障，那么就会导致进程读写请求一直获取不到资源，从而进程一直是不可中断状态，造成负载很高。

Reference：