系统性能查看命令vmstat iostat top

写在前面:top命令之前已经介绍过,链接为:https://www.cnblogs.com/move-on-change/p/9510491.html

这里要继续记录vmstat和iostat的用法,通常top命令排查后,还需要使用vmstat和iostat进一步观察。

一、vmstat命令

首先介绍vmstat命令的参数,然后解析其返回结果的含义。

1.1 vmstat(Virtual Memory Statistics 虚拟内存统计) 命令用来显示Linux系统虚拟内存状态,也可以报告关于进程、内存、I/O等系统整体运行状态。用法

vmstat [-a] [-n] [-t] [-S unit] [delay [ count]]
vmstat [-s] [-n] [-S unit]
vmstat [-m] [-n] [delay [ count]]
vmstat [-d] [-n] [delay [ count]]
vmstat [-p disk partition] [-n] [delay [ count]]
vmstat [-f]
vmstat [-V]
选项
-a:显示活跃和非活跃内存
-f:显示从系统启动至今的fork数量 。
-m:显示slabinfo
-n:只在开始时显示一次各字段名称。
-s:显示内存相关统计信息及多种系统活动数量。

delay:刷新时间间隔。如果不指定,只显示一条结果。

count:刷新次数。如果不指定刷新次数,但指定了刷新时间间隔,这时刷新次数为无穷。

-d:显示磁盘相关统计信息。

-p:显示指定磁盘分区统计信息

-S:使用指定单位显示。参数有 k 、K 、m 、M ,分别代表1000、1024、1000000、1048576字节(byte)。默认单位为K(1024 bytes)
-V:显示vmstat版本信息。
vmstat 1    1表示每秒采集一次
vmstat 2 1    2表示2秒采集一次,1表示只采集一次

1.2 vmstat命令返回结果

Procs(进程)
r:
运行队列中进程数量,就是说有多少个进程真的分配到CPU,这个值也可以判断是否需要增加CPU。当这个值超过了CPU数目,就会出现CPU瓶颈了。
b:
等待IO的进程数量,阻塞的进程。比如正在等待I/O、或者内存交换等。

Memory(内存)
swpd
使用虚拟内存大小切换到内存交换区的内存数量(k表示)。如果swpd的值不为0,或者比较大,比如超过了100m,只要si、so的值长期为0,系统性能还是正常。

free
空闲物理内存大小。(k)
buff
用作缓冲的内存大小。一般对块设备的读写才需要缓冲。
cache
用作缓存的内存大小,一般作为文件系统的cache,如果cache的值大的时候,说明cache处的文件数多,如果频繁访问到的文件都能被cache处,那么磁盘的读IO bi会非常小。

Swap
si
每秒从交换区写到内存的大小,由磁盘调入内存。
so
每秒写入交换区的内存大小,由内存调入磁盘。
注意:内存够用的时候,这2个值都是0,如果这2个值长期大于0时,系统性能会受到影响(会变慢),磁盘IO和CPU资源都会被消耗。有些朋友看到空闲内存(free)很少的或接近于0时,就认为内存不够用了,不能光看这一点,还要结合si和so,如果free很少,但是si和so也很少(大多时候是0),那么不用担心,系统性能这时不会受到影响的。因为linux总是先把内存用光
IO
bi
每秒读取的块数,从块设备读入数据的总量(读磁盘)(每秒kb)。
bo
每秒写入的块数,从块设备写入数据的总量(写磁盘)(每秒kb)。
注意:随机磁盘读写的时候,这2个值越大(如超出1024k),能看到CPU在IO等待的值也会越大。可以结合iostat输出进一步分析。

system(系统)
in
每秒CPU中断数,包括时钟中断。
cs
每秒上下文切换数。
注意:上面2个值越大,会看到由内核消耗的CPU时间会越大。

例如我们调用系统函数,就要进行上下文切换,线程的切换,也要进程上下文切换,这个值要越小越好,太大了,要考虑调低线程或者进程的数目,例如在apache和nginx这种web服务器中,我们一般做性能测试时会进行几千并发甚至几万并发的测试,选择web服务器的进程可以由进程或者线程的峰值一直下调,压测,直到cs到一个比较小的值,这个进程和线程数就是比较合适的值了。系统调用也是,每次调用系统函数,我们的代码就会进入内核空间,导致上下文切换,这个是很耗资源,也要尽量避免频繁调用系统函数。上下文切换次数过多表示你的CPU大部分浪费在上下文切换,导致CPU干正经事的时间少了,CPU没有充分利用,是不可取的。
CPU(以百分比表示)
us:
用户进程执行时间百分比(user time) us的值比较高时,说明用户进程消耗的CPU时间多,但是如果长期超50%的使用,那么我们就该考虑优化程序算法或者进行加速。
sy:
内核系统进程执行时间百分比(system time) sy的值高时,说明系统内核消耗的CPU资源多,这并不是良性表现,我们应该检查原因。

这里us + sy的参考值为80%,如果us+sy 大于 80%说明可能存在CPU不足。

wa:
IO等待时间百分比 wa的值高时,说明IO等待比较严重,这可能由于磁盘大量作随机访问造成,也有可能磁盘出现瓶颈(块操作)。
id:
空闲时间百分比

二、iostat命令

也可参考博客https://www.cnblogs.com/maomaochong123/p/8094233.html

首先介绍iostat命令的参数,然后解析其返回结果的含义。

简介
iostat主要用于监控系统设备的IO负载情况,iostat首次运行时显示自系统启动开始的各项统计信息,之后运行iostat将显示自上次运行该命令以后的统计信息。用户可以通过指定统计的次数和时间来获得所需的统计信息。

红框内为第一次输出的磁盘IO负载状况提供了关于自从系统启动以来的统计信息。随后的每一次输出则是每个间隔之间的平均IO负载状况。

2.1 iostat参数用法

语法
iostat [ options ] [ <interval> [ <count> ] ]
iostat 主要有三个操作项,options 操作项,interval指定统计时间间隔,count总共输出次数
iostat [ -c ] [ -d ] [ -h ] [ -N ] [ -k | -m ] [ -t ] [ -V ] [ -x ] [ -z ] [ device [...] | ALL ] [ -p [ device [,...] | ALL ] ] [ interval [ count ] ]
例如:iostat -d -k 2
参数 -d 表示,显示设备(磁盘)使用状态-k某些使用block为单位的列强制使用Kilobytes为单位2表示,数据显示每隔2秒刷新一次
输出如下

tips:该设备每秒的传输次数(Indicate the number of transfers per second that were issued to the device.)。"一次传输"意思是"一次I/O请求"。多个逻辑请求可能会被合并为"一次I/O请求"。"一次传输"请求的大小是未知的。

kB_read/s:每秒从设备(drive expressed)读取的数据量;
kB_wrtn/s:每秒向设备(drive expressed)写入的数据量;
kB_read:读取的总数据量;
kB_wrtn:写入的总数量数据量;这些单位都为Kilobytes。
-x 参数
iostat还有一个比较常用的选项-x,该选项将用于显示和io相关的扩展数据。

-c 参数
iostat还可以用来获取cpu部分状态值:
iostat -c 1 10

avg-cpu: %user %nice %sys %iowait %idle

1.98 0.00 0.35 11.45 86.22
a
avg-cpu: %user %nice %sys %iowait %idle

1.62 0.00 0.25 34.46 63.67
常用方法:
iostat -d -k 1 10 #查看TPS和吞吐量信息(磁盘读写速度单位为KB)
i
iostat -d -m 2 #查看TPS和吞吐量信息(磁盘读写速度单位为MB)
i
iostat -d -x -k 1 10 #查看设备使用率(%util)、响应时间(await)

iostat -c 1 10 #查看cpu状态
iostat -d -x -k 1

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 1.56 28.31 7.84 31.50 43.65 3.16 21.82 1.58 1.19 0.03 0.80 2.61 10.29
sda 1.98 24.75 419.80 6.93 13465.35 253.47 6732.67 126.73 32.15 2.00 4.70 2.00 85.25
sda 3.06 41.84 444.90 54.08 14204.08 2048.98 7102.04 1024.49 32.57 2.10 4.21 1.85 92.24
可以看到磁盘的平均响应时间<5ms,磁盘使用率>80。磁盘响应正常,但是已经很繁忙了。

2.2 iostat返回结果介绍
 iostat -d -k -x 1 2
Linux 3.0.101-0.47.52-default (NSMRF01) 07/31/18 _x86_64_

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 21.05 0.00 2.25 0.01 93.22 82.76 0.02 9.19 6.83 1.54

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
输出信息的含义
rrqm/s:每秒这个设备相关的读取请求有多少被Merge了(当系统调用需要读取数据的时候,VFS将请求发到各个FS,如果FS发现不同的读取请求读取的是相同Block的数据,FS会将这个请求合并Merge);

wrqm/s:每秒这个设备相关的写入请求有多少被Merge了。

r/s: 每秒完成的读 I/O 设备次数。即 delta(rio)/s
w/s: 每秒完成的写 I/O 设备次数。即 delta(wio)/s

rsec/s: 每秒读扇区数。即 delta(rsect)/s
wsec/s: 每秒写扇区数。即 delta(wsect)/s
rKB/s:The number of read requests that were issued to the device per second;
wKB/s:The number of write requests that were issued to the device per second;

avgrq-sz:平均每次设备I/O操作的数据大小 (扇区)。delta(rsect+wsect)/delta(rio+wio)
avgqu-sz:平均I/O队列长度。即 delta(aveq)/s/1000 (因为aveq的单位为毫秒)。
avgqu-sz 是平均请求队列的长度。毫无疑问,队列长度越短越好。
await:平均每次设备I/O操作的等待时间 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)每一个IO请求的处理的平均时间(单位是微秒毫秒)。这里可以理解为IO的响应时间,一般地系统IO响应时间应该低于5ms,如果大于10ms就比较大了。
这个时间包括了队列时间和服务时间,也就是说,一般情况下,await大于svctm它们的差值越小,则说明队列时间越短,反之差值越大,队列时间越长,说明系统出了问题。
svctm:平均每次设备I/O操作的服务时间 (毫秒)。即 delta(use)/delta(rio+wio)。如果svctm的值与await很接近,表示几乎没有I/O等待,磁盘性能很好,如果await的值远高于svctm的值,则表示I/O队列等待太长, 系统上运行的应用程序将变慢。
%util 在统计时间内所有处理IO时间,除以总共统计时间。例如,如果统计间隔1秒,该设备有0.8秒在处理IO,而0.2秒闲置,那么该设备的%util = 0.8/1 = 80%,所以该参数暗示了设备的繁忙程度。一般地,如果该参数是100%表示设备已经接近满负荷运行了(当然如果是多磁盘,即使%util是100%,因为磁盘的并发能力,所以磁盘使用未必就到了瓶颈)。: 

%idle(空闲)小于70% IO压力就较大了,一般读取速度有较多的wait.同时可以结合vmstat 查看查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比,高过30%时
IO压力高)

三、性能分析小结

IO/CPU/men连锁反应
    1.free急剧下降
    2.buff和cache被回收下降,但也无济于事
    3.依旧需要使用大量swap交换分区swpd
    4.等待进程数,b增多
    5.读写IO,bi bo增多
    6.si so大于0开始从硬盘中读取
    7.cpu等待时间用于 IO等待,wa增加
内存不足
    1.开始使用swpd,swpd不为0
    2.si so大于0开始从硬盘中读取
io瓶颈
    1.读写IO,bi bo增多超过2000
    2.cpu等待时间用于 IO等待,wa增加 超过20
    3.sy 系统调用时间长,IO操作频繁会导致增加 >30%
    4.wa io等待时间长
        iowait% <20%            良好
        iowait% <35%            一般
        iowait% >50%
    5.进一步使用iostat观察
CPU瓶颈:load,vmstat中r列
    1.反应为CPU队列长度
    2.一段时间内,CPU正在处理和等待CPU处理的进程数之和,直接反应了CPU的使用和申请情况。
    3.理想的load average:核数*CPU数*0.7
        CPU个数:grep 'physical id' /proc/cpuinfo | sort -u
        核数:grep 'core id' /proc/cpuinfo | sort -u | wc -l
    4.超过这个值就说明已经是CPU瓶颈了
CPU瓶颈
    1.us 用户CPU时间高超过90%
涉及到web服务器,cs 每秒上下文切换次数
    例如我们调用系统函数,就要进行上下文切换,线程的切换,也要进程上下文切换,这个值要越小越好,太大了,要考虑调低线程或者进程的数目,例如在apache和nginx这种web服务器中,我们一般做性能测试时会进行几千并发甚至几万并发的测试,选择web服务器的进程可以由进程或者线程的峰值一直下调,压测,直到cs到一个比较小的值,这个进程和线程数就是比较合适的值了。系统调用也是,每次调用系统函数,我们的代码就会进入内核空间,导致上下文切换,这个是很耗资源,也要尽量避免频繁调用系统函数。上下文切换次数过多表示你的CPU大部分浪费在上下文切换,导致CPU干正经事的时间少了,CPU没有充分利用,是不可取的。
    1.cs可以对apache和nginx线程和进程数限制起到一定的参考作用
    2.我们一般做性能测试时会进行几千并发甚至几万并发的测试,选择web服务器的进程可以由进程或者线程的峰值一直下调,压测,直到cs到一个比较小的值,这个进程和线程数就是比较合适的值了
较好的趋势:主要是 swap使用少,swpd数值低。si so分页读取写入数值趋近于零


 

原文地址:https://www.cnblogs.com/move-on-change/p/9510995.html