Linux系统下CPU使用(load average)梳理

2019-08-14 13:18:59

参考文档 Linux系统下CPU使用(load average)梳理

在平时的运维工作中，当一台服务器的性能出现问题时，通常会去看当前的CPU使用情况，尤其是看下CPU的负载情况(load average)。对一般的系统来说，根据cpu数量去判断。比如有2颗cup的机器。如果平均负载始终在1.2以下，那么基本不会出现cpu不够用的情况。也就是Load平均要小于Cpu的数量。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
对于cpu负载的理解，首先需要搞清楚下面几个问题：
  
1）系统load高不一定是性能有问题。
因为Load高也许是因为在进行cpu密集型的计算
  
2）系统Load高不一定是CPU能力问题或数量不够。
因为Load高只是代表需要运行的队列累计过多了。但队列中的任务实际可能是耗Cpu的，也可能是耗i/0或者其他因素的。
  
3）系统长期Load高，解决办法不是一味地首先增加CPU
因为Load只是表象，不是实质。增加CPU个别情况下会临时看到Load下降，但治标不治本。
  
4）在Load average 高的情况下需要鉴别系统瓶颈到底是CPU不足，还是io不够快造成或是内存不足造成的。
  
===============================================================================================================
要想获得服务器的CPU负载情况，有下面几种命令：
1）w命令
[root@localhost ~]# w
 12:12:41 up 167 days, 20:46,  2 users,  load average: 0.00, 0.01, 0.05
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
root     pts/0    192.168.1.5      10:01    1.00s  0.11s  0.00s w
root     pts/2    192.168.1.5      10:19    1:47m  0.04s  0.04s -bash
   
2）uptime命令（一般首先会根据最后那个15分钟的load负载为准）
[root@localhost ~]# uptime
 12:12:55 up 167 days, 20:46,  2 users,  load average: 0.00, 0.01, 0.05
   
3）top命令
[root@localhost ~]# top
top - 12:13:22 up 167 days, 20:47,  2 users,  load average: 0.00, 0.01, 0.05
Tasks: 272 total,   1 running, 271 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  0.1 sy,  0.0 ni, 99.9 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 65759080 total, 58842616 free,   547908 used,  6368556 buff/cache
KiB Swap:  2097148 total,  2097148 free,        0 used. 64264884 avail Mem
................
  
对上面第三行的解释：
us（user cpu time）：用户态使用的cpu时间比。该值较高时，说明用户进程消耗的 CPU 时间比较多，比如，如果该值长期超过 50%，则需要对程序算法或代码等进行优化。
sy（system cpu time）：系统态使用的cpu时间比。
ni（user nice cpu time）：用做nice加权的进程分配的用户态cpu时间比
id（idle cpu time）：空闲的cpu时间比。如果该值持续为0，同时sy是us的两倍，则通常说明系统则面临着 CPU 资源的短缺。
wa（io wait cpu time）：cpu等待磁盘写入完成时间。该值较高时，说明IO等待比较严重，这可能磁盘大量作随机访问造成的，也可能是磁盘性能出现了瓶颈。
hi（hardware irq）：硬中断消耗时间
si（software irq）：软中断消耗时间
st（steal time）：虚拟机偷取时间
  
以上解释的这些参数的值加起来是100%。
  
4）vmstat
[root@localhost ~]# vmstat
procs -----------memory---------------------swap-------io---------system--------cpu-----
r  b      swpd   free    buff   cache    si   so    bi    bo     in   cs     us sy id wa st
3  0      0      1639792 724280 4854236  0    0     4     34     4    0      19 45 35  0  0
  
解释说明：
-----------------------------
procs部分的解释
r 列表示运行和等待cpu时间片的进程数，如果长期大于1，说明cpu不足，需要增加cpu。
b 列表示在等待资源的进程数，比如正在等待I/O、或者内存交换等。
-----------------------------
cpu部分的解释
us 列显示了用户方式下所花费 CPU 时间的百分比。us的值比较高时，说明用户进程消耗的cpu时间多，但是如果长期大于50%，需要考虑优化用户的程序。
sy 列显示了内核进程所花费的cpu时间的百分比。这里us + sy的参考值为80%，如果us+sy 大于 80%说明可能存在CPU不足。
wa 列显示了IO等待所占用的CPU时间的百分比。这里wa的参考值为30%，如果wa超过30%，说明IO等待严重，这可能是磁盘大量随机访问造成的，也可能磁盘或者
   磁盘访问控制器的带宽瓶颈造成的(主要是块操作)。
id 列显示了cpu处在空闲状态的时间百分比
-----------------------------
system部分的解释
in 列表示在某一时间间隔中观测到的每秒设备中断数。
cs列表示每秒产生的上下文切换次数，如当 cs 比磁盘 I/O 和网络信息包速率高得多，都应进行进一步调查。
-----------------------------
memory部分的解释
swpd 切换到内存交换区的内存数量(k表示)。如果swpd的值不为0，或者比较大，比如超过了100m，只要si、so的值长期为0，系统性能还是正常
free 当前的空闲页面列表中内存数量(k表示)
buff 作为buffer cache的内存数量，一般对块设备的读写才需要缓冲。
cache: 作为page cache的内存数量，一般作为文件系统的cache，如果cache较大，说明用到cache的文件较多，如果此时IO中bi比较小，说明文件系统效率比较好。
-----------------------------
swap部分的解释
si 由内存进入内存交换区数量。
so由内存交换区进入内存数量。
-----------------------------
IO部分的解释
bi 从块设备读入数据的总量（读磁盘）（每秒kb）。
bo 块设备写入数据的总量（写磁盘）（每秒kb）
  
  
5）也可以使用dstat命令查看cpu信息
[root@localhost ~]# dstat
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw
 19  45  35   0   0   0|  30k  265k|   0     0 |   0     0 |9025    12k
  9  18  73   0   0   0|   0   144k|2578k   65k|   0     0 |3956  4343
  
6）可以使用iostat查看IO负载
[root@localhost ~]# iostat 1 1
Linux 2.6.32-696.16.1.el6.x86_64 (nc-ftp01.kevin.cn)    2017年12月29日     _x86_64_    (4 CPU)
  
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          19.32    0.00   45.44    0.06    0.26   34.93
  
Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
xvda             14.17        29.94       265.17   63120486  558975100
 
解释说明：
avg-cpu: 总体cpu使用情况统计信息，对于多核cpu，这里为所有cpu的平均值
%user: 在用户级别运行所使用的CPU的百分比.
%nice: nice操作所使用的CPU的百分比.
%sys: 在系统级别(kernel)运行所使用CPU的百分比.
%iowait: CPU等待硬件I/O时,所占用CPU百分比.
%idle: CPU空闲时间的百分比.
 
Device段:各磁盘设备的IO统计信息
tps: 每秒钟发送到的I/O请求数.
Blk_read /s: 每秒读取的block数.
Blk_wrtn/s: 每秒写入的block数.
Blk_read:   读入的block总数.
Blk_wrtn:  写入的block总数.
 
[root@localhost ~]# iostat -x -k -d 1
Linux 2.6.32-696.el6.x86_64 (centos6-vm02)  01/04/2018  _x86_64_    (4 CPU)
 
Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
scd0              0.00     0.00    0.00    0.00     0.00     0.00     8.00     0.00    0.36    0.36    0.00   0.36   0.00
vda               0.01     0.13    0.04    0.13     0.60     0.89    18.12     0.00    2.78    0.19    3.53   2.55   0.04
dm-0              0.00     0.00    0.04    0.22     0.58     0.88    11.25     0.00    3.27    0.25    3.82   1.61   0.04
dm-1              0.00     0.00    0.00    0.00     0.00     0.00     8.00     0.00    0.13    0.13    0.00   0.04   0.00
dm-2              0.00     0.00    0.00    0.00     0.00     0.00     7.91     0.00    0.19    0.10    5.00   0.16   0.00
 
解释说明：
rrqm/s: 每秒对该设备的读请求被合并次数，文件系统会对读取同块(block)的请求进行合并
wrqm/s: 每秒对该设备的写请求被合并次数
r/s: 每秒完成的读次数
w/s: 每秒完成的写次数
rkB/s: 每秒读数据量(kB为单位)
wkB/s: 每秒写数据量(kB为单位)
avgrq-sz:平均每次IO操作的数据量(扇区数为单位)
avgqu-sz: 平均等待处理的IO请求队列长度
await: 平均每次IO请求等待时间(包括等待时间和处理时间，毫秒为单位)
svctm: 平均每次IO请求的处理时间(毫秒为单位)
%util: 采用周期内用于IO操作的时间比率，即IO队列非空的时间比率
 
如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。
idle小于70% IO压力就较大了,一般读取速度有较多的wait。
同时可以结合vmstat 查看查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比,高过30%时IO压力高)

简单说下CPU负载和CPU利用率的区别

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
0）load average：系统平均负载是CPU的Load，它所包含的信息不是CPU的使用率状况，而是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息，
   也就是CPU使用队列的长度的统计信息，这个数字越小越好。
 
1）CPU使用率：显示的是程序在运行期间实时占用的CPU百分比。
 
2）CPU负载：显示的是一段时间内正在使用和等待使用CPU的平均任务数。CPU使用率高，并不意味着负载就一定大。
举例来说：如果我有一个程序它需要一直使用CPU的运算功能，那么此时CPU的使用率可能达到100%，但是CPU的工作负载则是趋近于"1"，因为CPU仅负责一个工作啊。
如果同时执行这样的程序两个呢？CPU的使用率还是100%，但是工作负载则变成2了。所以也就是说，当CPU的工作负载越大，代表CPU必须要在不同的工作之间进行频繁
的工作切换。
 
  
3）CPU利用率高，并不意味着负载就一定大。
举例来说：
如果有一个程序它需要一直使用CPU的运算功能，那么此时CPU的使用率可能达到100%，但是CPU的工作负载则是趋近于"1"，因为CPU仅负责一个工作！
如果同时执行这样的程序两个呢？CPU的使用率还是100%，但是工作负载则变成2了。所以也就是说，当CPU的工作负载越大，代表CPU必须要在不同的工作之间
进行频繁的工作切换。
   
------------------------下面通过一个电话亭打电话的比喻来说明这两者之间的区别------------------------
某公用电话亭，有一个人在打电话，四个人在等待，每人限定使用电话一分钟，若有人一分钟之内没有打完电话，只能挂掉电话去排队，等待下一轮。
电话在这里就相当于CPU，而正在或等待打电话的人就相当于任务数。
   
在电话亭使用过程中，肯定会有人打完电话走掉，有人没有打完电话而选择重新排队，更会有新增的人在这儿排队，这个人数的变化就相当于任务数的增减。
为了统计平均负载情况，我们5分钟统计一次人数，并在第1、5、15分钟的时候对统计情况取平均值，从而形成第1、5、15分钟的平均负载。
   
有的人拿起电话就打，一直打完1分钟，而有的人可能前三十秒在找电话号码，或者在犹豫要不要打，后三十秒才真正在打电话。如果把电话看作CPU，人数看
作任务，我们就说前一个人（任务）的CPU利用率高，后一个人（任务）的CPU利用率低。当然， CPU并不会在前三十秒工作，后三十秒歇着，只是说，有的程
序涉及到大量的计算，所以CPU利用率就高，而有的程序牵涉到计算的部分很少，CPU利用率自然就低。但无论CPU的利用率是高是低，跟后面有多少任务在排队
没有必然关系。

=========正确理解%iowait和CPU使用率=========

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
1）%steal
一般是在虚拟机中才能看到数值，比如CPU overcommitment很严重的VPS，而%guest和%nice一般都很低,所以也可以
根据/proc/stat或者top可得，user + nice + system + idle + iowait + irq + softirq + steal = 100
 
2）Linux进程状态
运行状态（TASK_RUNNING）：
　　是运行态和就绪态的合并，表示进程正在运行或准备运行，Linux 中使用TASK_RUNNING 宏表示此状态
可中断睡眠状态（浅度睡眠）（TASK_INTERRUPTIBLE）：
　　进程正在睡眠（被阻塞），等待资源到来是唤醒，也可以通过其他进程信号或时钟中断唤醒，进入运行队列。Linux 使用TASK_INTERRUPTIBLE 宏表示此状态。
不可中断睡眠状态（深度睡眠状态）（TASK_UNINTERRUPTIBLE）：
　　其和浅度睡眠基本类似，但有一点就是不可被其他进程信号或时钟中断唤醒。Linux 使用TASK_UNINTERRUPTIBLE 宏表示此状态。
暂停状态（TASK_STOPPED）：
　　进程暂停执行接受某种处理。如正在接受调试的进程处于这种状态，Linux 使用TASK_STOPPED 宏表示此状态。
僵死状态（TASK_ZOMBIE）：
　　进程已经结束但未释放PCB，Linux 使用TASK_ZOMBIE 宏表示此状态。
 
3）%iowait 的正确认知
%iowait 表示在一个采样周期内有百分之几的时间属于以下情况：CPU空闲、并且有仍未完成的I/O请求。
 
对 %iowait 常见的误解有两个：
　　一是误以为 %iowait 表示CPU不能工作的时间，
　　二是误以为 %iowait 表示I/O有瓶颈。
 
首先 %iowait 升高并不能证明等待I/O的进程数量增多了，也不能证明等待I/O的总时间增加了。
例如：
在CPU繁忙期间发生的I/O，无论IO是多还是少，%iowait都不会变；
当CPU繁忙程度下降时，有一部分IO落入CPU空闲时间段内，导致%iowait升高。
再比如：IO的并发度低，%iowait就高；IO的并发度高，%iowait可能就比较低。
 
可见%iowait是一个非常模糊的指标，如果看到 %iowait 升高，还需检查I/O量有没有明显增加，
avserv/avwait/avque等指标有没有明显增大，应用有没有感觉变慢，如果都没有，就没什么好担心的。
 
4）查看CPU使用率，推荐如下Linux命令：
# top
# sar -u 1 5
# vmstat -n 1 5
# mpstat -P ALL 1 5
 
查看Load的值，推荐如下Linux命令：
# top
# uptime
# sar -q 1 5

load average相关梳理（一分钟，五分钟，十五分钟的平均CPU负载，最重要的指标是最后一个数字，即前15分钟的平均CPU负载，这个数字越小越好。所谓CPU负载指的是一段时间内任务队列的长度，通俗的讲，就是一段时间内一共有多少任务在使用或等待使用CPU。（当前的"负载值除以cpu核数"就是cpu的利用率））

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
load average表示的是系统的平均负荷，即CPU的Load。
它所包含的信息不是CPU的使用率状况，而是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息，也就是CPU使用队列的长度的统计信息。
它包括3个数字，分别表示系统在1、5、15分钟内进程队列中的平均进程数量（即处理的进程情况），
原则上来说这3个数字越小越好，数字越小表示服务器的工作量越小，系统负荷比较轻
  
当CPU完全空闲的时候，平均负荷为0（即load average的值为0）；当CPU工作量饱和的时候，平均负荷为1。
  
这里需要注意的是：
load average这个输出值，这三个值的大小一般不能大于系统逻辑CPU的个数
比如一台服务器有4个逻辑CPU，如果load average的三个值长期大于4时，说明CPU很繁忙，负载很高，可能会影响系统性能；
但是偶尔大于4时，倒不用担心，一般不会影响系统性能。
相反，如果load average的输出值小于CPU的个数，则表示CPU还有空闲，比如本例中的输出，CPU是比较空闲的。
  
  
-------------load average举例理解---------------
判断系统负荷是否过重，必须理解load average的真正含义。假设当前我的一台服务器只有一个CPU，所有的运算都必须由这个CPU来完成。
不妨把这个CPU想象成一座大桥，桥上只有一根车道，所有车辆都必须从这根车道上通过（很显然，这座桥只能单向通行）。
1）系统负荷为0，意味着大桥上一辆车也没有。
2）系统负荷为0.5，意味着大桥一半的路段有车。
3）系统负荷为1.0，意味着大桥的所有路段都有车，也就是说大桥已经"满"了。但是必须注意的是，直到此时大桥还是能顺畅通行的。
4）系统负荷为1.7，意味着车辆太多了，大桥已经被占满了（100%），后面等着上桥的车辆为桥面车辆的70%。
   以此类推，系统负荷2.0，意味着等待上桥的车辆与桥面的车辆一样多；
   系统负荷3.0，意味着等待上桥的车辆是桥面车辆的2倍。
   总之，当系统负荷大于1，后面的车辆就必须等待了；系统负荷越大，过桥就必须等得越久。
  
CPU的系统负荷，基本上等同于上面的类比。大桥的通行能力，就是CPU的最大工作量；桥梁上的车辆，就是一个个等待CPU处理的进程（process）。
如果CPU每分钟最多处理100个进程，那么：
系统负荷0.2，意味着CPU在这1分钟里只处理20个进程；
系统负荷1.0，意味着CPU在这1分钟 里正好处理100个进程；
系统负荷1.7，意味着除了CPU正在处理的100个进程以外，还有70个进程正排队等着CPU处理。
  
为了服务器顺畅运行，系统负荷最好不要超过1.0，这样就没有进程需要等待了，所有进程都能第一时间得到处理。
很显然，1.0是一个关键值，超过这个值，系统就不在最佳状态了，就需要动手干预了。
  
  
--------1.0是系统负荷的理想值吗？-----------
不一定，系统管理员往往会留一点余地，当这个值达到0.7，就应当引起注意了。
以往经验是这样的：
当系统负荷持续大于0.7，必须开始调查了，问题出在哪里，防止情况恶化。
当系统负荷持续大于1.0，必须动手寻找解决办法，把这个值降下来。
当系统负荷达到5.0，就表明系统有很严重的问题，长时间没有响应，或者接近死机了。觉不能让系统达到这个值。
  
  
上面，假设我的这台服务器只有1个CPU。如果它装了2个CPU，就意味着服务器的处理能力翻了一倍，能够同时处理的进程数量也翻了一倍。
还是用大桥来类比，两个CPU就意味着大桥有两根车道了，通车能力翻倍了。
所以，2个CPU表明系统负荷可以达到2.0，此时每个CPU都达到100%的工作量。推广开来，n个CPU的服务器，可接受的系统负荷最大为n.0。
  
  
---------至于load average是多少才算理想，这个有争议，各有各的说法---------
个人比较赞同CPU负载小于等于"内核数乘以0.5-0.7"算是一种理想状态。
比如4核CPU的服务器，理想负载是小于等于2，最好不要超过2.8，否则性能多少会受影响。
  
不管某个CPU的性能有多好，1秒钟能处理多少任务，可以认为它无关紧要，虽然事实并非如此。
在评估CPU负载时，只以5分钟为单位做统计任务队列长度。如果每隔5分钟统计的时候，发现任务队列长度都是1，那么CPU负载就为1。
  
假如现在某台服务器只有一个单核的CPU，负载一直为1，意味着没有任务在排队，还不错。
但是这台服务器是双核CPU，等于是有4个内核，每个内核的负载为1的话，总负载为4。这就是说，如果这台服务器的CPU负载长期保持在4左右，还可以接受。
但是每个内核的负载为1，并不能算是一种理想状态！这意味着服务器的CPU一直很忙，不得清闲。
  
  
-----------load average返回三个平均值应该参考哪个值？------------
如果只有1分钟的系统负荷大于1.0，其他两个时间段都小于1.0，这表明只是暂时现象，问题不大。
如果15分钟内，平均系统负荷大于1.0（调整CPU核心数之后），表明问题持续存在，不是暂时现象。
所以应该主要观察"15分钟系统负荷"，将它作为服务器正常运行的指标。
  
----------如何来降低服务器的CPU负载？--------------
最简单办法的是更换性能更好的服务器，不要想着仅仅提高CPU的性能，那没有用，CPU要发挥出它最好的性能还需要其它软硬件的配合。
在服务器其它方面配置合理的情况下，CPU数量和CPU核心数（即内核数）都会影响到CPU负载，因为任务最终是要分配到CPU核心去处理的。两块CPU要比一块
CPU好，双核要比单核好。因此，需要记住的是：除去CPU性能上的差异，CPU负载是基于内核数来计算的。有一个说法是"有多少内核，即有多少负载"。


  • 精彩推荐

  • 2021-01-13 17:23:21

    CREATE TABLE 表名 AS SELECT 语句 快速复制表但是锁表

    注意Table2的主键约束，如果Table2有主键而且不为空，则 field1， field2…中必须包括主键 在执行语句的时候，MySQL是逐行加锁的（扫描一个锁一个），直至锁住所有符合条件的数据，执行完毕才释放锁。所以当业务在进行的时候，切忌使用这种方法。 在RR隔离级别下，还会加行锁和间隙锁

  • 2021-01-13 17:27:04

    Navicat配置mysql数据库用户权限

    用数据库的时候就会遇到有多个用户,分配用户权限的情况，有些用户只读，有些用户可以读写，有些用户只能操作一个或者多个数据库，如何给mysql的用户设置权限，我这里描述一下如何用navicat图形操作分配用户权限

  • 2021-01-14 06:15:04

    通过glide获取图片显示后的真正宽高

    有时候需要获取网络图片的宽高来设置图片显示的大小，很多人会直接利用Glide的加载监听去拿图片的宽高，但是这样拿到的不是图片真正的宽高，而是图片显示在ImageView后的宽高。如下：

  • 2021-01-14 09:38:57

    Chrome插件详细教程

    严格来讲，我们正在说的东西应该叫Chrome扩展(Chrome Extension)，真正意义上的Chrome插件是更底层的浏览器功能扩展，可能需要对浏览器源码有一定掌握才有能力去开发。鉴于Chrome插件的叫法已经习惯，本文也全部采用这种叫法，但读者需深知本文所描述的Chrome插件实际上指的是Chrome扩展。

  • 2021-01-14 17:07:51

    chrome.contextMenus.create不出现菜单

    主要原因是，我每次刷新玩，都复制一下右键，然而并没有出现菜单，一度颓废啊，因为demo，还有其他人的文章都是这样的。 哎，后来发现是这样的，我缺少了contexts选项。其实我是成功了，我现在只要不选择文字，直接点右键，菜单已经出现了哦。

  • 2021-01-15 13:06:08

    监控 MongoDB -

    随着MongoDB中保存的数据越来越多，对MongoDB服务状态的监控也越来越重要，经常关注服务是否健康，才能防止故障以及优化。