Linux运维之系统性能瓶颈工具vmstat分析

vmstat是一个很好用的检测系统性能工具，没有过多的参数，直接一个vmstat命令即可，不过我们一般加上-w表示宽格式输出。然后再附加上侦测时间即可

例如：

vmstat  -w  3  100

表示每3秒检测一次并输出系统信息，一共输出100次。

这样的格式的命令很好用，接下来我们运行一下这个命令并对输出的数据进行分析

[root@:vg_adn_tidbCkhsTest:54.158.254.36:172.31.30.62 ~/tidb-bench/sysbench]#vmstat -w 3 100
procs -----------------------memory---------------------- ---swap-- -----io---- -system-- --------cpu--------
 r  b         swpd         free         buff        cache   si   so    bi    bo   in   cs  us  sy  id  wa  st
15  0            0     24466112         1476      2454284    0    0    95   101    2    2   3   0  97   0   0

参数讲解：

r：The number of runnable processes (running or waiting for run time).

　　表示当前运行队列中运行或等待CPU时间片的进程的数目，代表线程处于可运行状态，但CPU还未能执行。大家不要误认为等待CPU时间片意味着这个进程没有运行，实际上某一时刻1个CPU只能有一个进程占用，其他的进程只能排着队等着，此时这些排队等待CPU资源的进程依然是运行状态。这个值如果长期大于系统CPU的逻辑个数，说明CPU不足，需要增加CPU的个数。
b: The number of processes in uninterruptible sleep.
　　表示处在非中断睡眠状态的进程数。通俗的说就是表示在等待资源的进程数，比如正在等待I/O或者内存交换等。举个例子，当磁盘读写非常频繁时，写入数据就会非常慢，此时CPU运算很快就结束了，但进程需要把计算的结果写入磁盘，这样进程的任务才算完成，那此时这个进程只能慢慢地等待磁盘了，这样这个进程就是这个b状态。该数值如果长时间大于1，则需要关注一下了。
us: Time spent running non-kernel code.
　　表示用户进程消耗的CPU利用率的百分比。us的值比较高时，说明用户进程消耗的CPU时间多，但是如果长期大于50%，就需要考虑优化程序和算法
sy: Time spent running kernel code.
　　表示内核进程消耗的CPU时间的百分比，sy的值越高时，说明内核消耗的CPU资源很多。
注意：us+sy：参考值为80%，如果us+sy这个值大于80%说明可能存在CPU资源不足。
id: Time spent idle.  Prior to Linux 2.5.41, this includes IO-wait time.
　　CPU空闲时间的百分比。如果这个值很小，表示CPU没有空闲时间，一直处于忙碌状态。
wa: Time spent waiting for IO.  Prior to Linux 2.5.41, included in idle　　
　　所有可运行状态线程被阻塞在等待IO请求的百分比
cs: The number of context switches per second
　　当前kernel system中，发生上下文切换的数目。系统中越多的上下文切换，在处理器的调度管理下，内核将得到更多的工作。
in: The number of interrupts per second, including the clock。
　  当前中断被处理的数目

swpd :the amount of virtual memory used. KB
　　当前虚拟内存使用的总额（KB）。当空闲内存极少的时候，更多的数据将被转换到交换设备中。
free：the amount of idle memory. KB
　　当前内存中可用的空间字节数
buff：the amount of idle memory.
　　表示（即将写入磁盘的）缓冲大小，KB
cache：the amount of memory used as cache
　　表示（从磁盘中读取的）缓冲大小，KB
si: Amount of memory swapped in from disk (/s)
　　从交换区写入内存的字节数总额，KB
so: Amount of memory swapped to disk (/s)
　　从内存写入交换区的字节数总额。KB
注意：如果内存不够用了，这两列的数值比较高。说明内存中的数据频繁交换到交换分区swap中，这往往对系统性能影响较大。
bi: Blocks received from a block device (blocks/s)
　　读磁盘，KB
bo：Blocks sent to a block device (blocks/s)
　　写磁盘，KB
注意：如果磁盘IO压力很大，这两列的数值会比较高。
可以使用iostat -x命令来查看详细信息。

案例一、

最近使用sysbench在做mysql数据库的压力测试，已经设置了较大的innodb_buffer_pool的值。在测试过程中我们对系统的性能进行了分析：

[root@:vg_adn_tidbCkhsTest:54.158.254.36:172.31.30.62 ~/tidb-bench/sysbench]#vmstat 3 100
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b    swpd   free     buff  cache    si   so    bi    bo   in   cs   us sy  id wa st
67  0      0  24610424   1476 2424032    0    0    95   101    1    2    3  0  97  0  0
64  0      0  24610356   1476 2424072    0    0     0     0 51859 28739 69  31  0  0  0
62  0      0  24609760   1476 2424832    0    0   235     0 51815 28698 68  32  0  0  0
59  0      0  24609592   1476 2424832    0    0     0     0 51894 28751 69  31  0  0  0
63  0      0  24608740   1476 2424864    0    0     5     0 52030 28753 68  32  0  0  0

这个例子很明显是个系统性能方面的问题。我们来分析一下：

1、从上面的r列可以看出，很多线程在等待CPU的执行。b列看出I/O或内存方面没有对CPU造成大的影响，说明瓶颈不在IO设备上，

2、并且我们通过wa列也可以得出结论IO请求比不高。我们再来关注us列和sy列，us列的值比较高，说明当前用户的mysql进程占用CPU资源比较高，sy说明内核进程占用比也比较高。造成内核进程占用比高的原因是内核在进行上下文的切换，不难看出确实此时的cs列的请求数挺高的。

3、us+sy的值大概有100%，我们的mysql在单台机器上测试的，与网络的关系不大。这个值高于80%，需要多考虑一下CPU方面了。

4、cs的上下文切换高于in的中断数目，说明内核中相当数量的时间都开销在中断请求数目上。

因此得出结论：我们这台机器的性能瓶颈大概是在CPU上，因为CPU的逻辑个数确实不多，才4个。因此造成CPU的忙碌运行。接下来我们以提高CPU的执行效率为主来考虑。

案例二、

procs -----------------------memory---------------------- ---swap-- -----io---- -system-- --------cpu--------
 r  b         swpd         free         buff        cache   si   so    bi    bo   in   cs  us  sy  id  wa  st
20  1            0     19135476       132432      6400624    0    0     0 36949 37619 20303  79  19   1   0   0
25  1            0     19130916       132432      6404780    0    0     0 36441 37495 20000  79  20   1   0   0
30  1            0     19127628       132436      6409060    0    0     0 35024 37774 20280  80  19   1   0   0
28  2            0     19123456       132436      6412836    0    0     0 36896 37451 20089  78  21   1   0   0
31  2            0     19119352       132436      6417288    0    0     0 35761 37466 20085  79  20   1   0   0

这个例子我们也来分析一下：

1、首先通过r列可以得出结论说明线程等待CPU执行的个数比较多，那么此时CPU肯定是忙碌的状态。

2、通过id列可以看出来CPU空闲时间确实挺少的，说明CPU确实忙碌。

3、通过内存的那几列可以看出内存不是瓶颈的因素

4、通过bo列可以看出此时在进行写磁盘操作，那么我们可以得出结论有可能是磁盘的瓶颈导致CPU的瓶颈，那么我们就要开始验证一下是否是这样子的原因。

5、通过b列可以看出这个值偶尔大于1，再看看wa列，wa列则表示IO等待所占用的CPU的百分比，不过wa列的值挺小的，说明瓶颈不在磁盘上。

6、因此我们可以得出结论是CPU自己达到了瓶颈，我们可以更换高配置的CPU来解决问题。

案例三：

procs memoryswapiosystemcpur
r  b     swpd  free  buff  cache   si     so  bi  bo  in    cs   us    sy  id  wa
17 0     1250  3248  45820 1488472 30    132 992  0   2437 7657  23   50 　　0  23
11 0 　　1376  3256  45820  1488888 57    245 416  0   2391 7173  10   90　  0  0
12 0 　　1582  1688  45828  1490228 63    131 1348 76  2432 7315  10   90 　　0 10
12 2 　　3981  1848  45468  1489824 185   56  2300 68  2478 9149  15   12 　　0 73
14 2　　 10385 2400  44484  1489732 0     87  1112 20  2515 11620  0   12 　　0 88
14 2 　　12671 2280  43644  1488816 76    51  1812 204 2546 11407 20   45 　　0 35

1、从r列与id列可以看出CPU处于忙碌的状态。

2、从swap列可以看出值在增大，说明有大量数据从内存转换到交换空间。再从free列可以看出空闲内存减少，是因为有大量请求（bi）转换到内存中。

3、内存free的减少导致系统写入swpd设备的块数目(so)和swap空间在不断增加。

4、从wa列可以看出大量的IO请求导致CPU的效率低下。

5、因此我们得出结论是I/O请求导致的CPU的效率低下，（当然也有可能CPU的执行效率也不高，但是你的先排除除了CPU之外的设备的瓶颈，最后在查看CPU的瓶颈）

案例四：

# vmstat 1 10
procs memory swap io system cpu
r b swpd   free  buff  cache    si so bi  bo 　　in   cs 　　us sy  id  wa
1 0 249844 19144 18532 1221212  0  0  7    3 　　22   17 　　25  8  17  18
0 1 249844 17828 18528 1222696  0  0 40448 8 　　1384 1138  13  7  65  14
0 1 249844 18004 18528 1222756  0  0 13568 4 　　623  534 　 3  4   56  37
2 0 249844 17840 18528 1223200  0  0 35200 0 　　1285 1017 　17 7  56   20
1 0 249844 22488 18528 1218608  0  0 38656 0 　　1294 1034 　17 7  58   18
0 1 249844 21228 18544 1219908  0  0 13696 484   609 559 　　5  3  54   38
0 1 249844 17752 18544 1223376  0  0 36224 4 　　1469 1035 　10 6  67   17
1 1 249844 17856 18544 1208520  0  0 28724 0 　　950  941 　 33 12 49   7
1 0 249844 17748 18544 1222468  0  0 40968 8 　　1266 1164 　17 9  59   16
1 0 249844 17912 18544 1222572  0  0 41344 12 　 1237 1080 　13 8  65   13

1、从内存方面我们看出来，swpd列的值始终没有变化，并且si和so的值也没有变化。

2、空闲内存free的值虽然不高，但是由于swap没有发生变化说明与内存的关系不大。

3、CPU方面也没有太大的问题，尽管有一些运行队列r，但处理器还有始终50%多的idle（CPU id）

4、CPU还有平均20%的I/O等待情况。

5、结论：这是一个I/O瓶颈的问题。

案例五、

[root@:vg_adn_tidbCkhsTest:54.158.254.36:172.31.30.62 /dev/data]#vmstat -w 3 100
procs -----------------------memory---------------------- ---swap-- -----io---- -system-- --------cpu--------
 r  b         swpd         free         buff        cache   si   so    bi    bo   in   cs  us  sy  id  wa  st
15  1            0       221736       132832     14142460    0    0    91   120    1    1   3   0  97   0   0
39  0            0       224572       132836     14128024    0    0     0 78357 43930 57823  59  25  10   6   0
24  3            0       226932       132836     14112496    0    0     0 78351 45233 58913  64  27   6   3   0
17  1            0       231532       132832     14096368    0    0     0 78271 43600 55667  63  26   7   3   0
25  1            0       230788       132832     14084196    0    0     8 76889 45326 61036  61  27   9   4   0
 2  2            0       229664       132832     14073200    0    0     0 78984 44279 54078  65  26   6   3   0
20  1            0       212588       132836     14078364    0    0     0 75559 44687 54993  65  26   6   3   0
37  2            0       212308       132828     14066684    0    0     0 82573 44591 57873  63  26   8   3   0
21  0            0       208936       132832     14056368    0    0     0 91479 43920 54727  64  27   6   3   0
 2  1            0       211868       132832     14041520    0    0     0 92304 42619 55316  65  26   6   2   0
 0  1            0       232676       132824     14017956    0    0     0 114328 27546 34453   2   4  72  21   0
 0  3            0       225940       132832     14024544    0    0     0 91408 21580 24824   3   4  67  26   0
 0  2            0       232532       132828     14013068    0    0     0 92092 34802 47947  18  10  46  25   0
11  1            0       226364       132828     14011320    0    0     0 73961 39283 50904  41  18  27  14   0
10  0            0       216000       132824     14012016    0    0     0 75463 45527 60788  61  25  10   4   0
 8  2            0       230808       132824     13984236    0    0     0 71920 44469 56487  65  27   5   3   0

这是一个在做mysql数据库性能压测的例子，我们使用sysbench工具对其进行insert操作，在128线程下进行的压测，数据库表是100万行数据，一共10个表。

1、既然是做insert操作，想必磁盘IO肯定会比较高，因此我们先看bo列，bo列的值基本在70Mb/s的速度之上。

2、我们再看r列，128线程的操作，此时的r列值不算太高，说明CPU是在高负载下运行。并且id列的值有一部分时刻也没有接近于0。

3、当bo列的值某一时刻开始增高的时候，说明IO吞吐量此时加大了。这个时候r列的值几乎为0，说明之前CPU的负载过高是磁盘IO过低导致的。而现在磁盘IO升高了那么此时的CPU已经能完成磁盘写操作（我们来看id列，确实CPU此时空闲了），既然磁盘这一时刻的性能变高了，吞吐量变大了，那么不难得出b值肯定会高，事实上也是b列的值确实增高了，wa的值也增高了。

4、因此我们可以看出这个压测主要影响在磁盘的性能上，如果有必要我们可以更换更好的高吞吐量的硬盘。

本片部分内容节选自系链接，大家也可以看看：https://blog.csdn.net/achang21/article/details/44041535