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
