优质博文:
一、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:


发布评论