Linux系统性能分析--iostat,vmstat...

Linux系统性能分析--iostat,vmstat...
1.iostat
2.vmstat
3.ifstat
4.iftop
5.iotop
6.top
7.lsof

1.iostat
iostat用来动态监视系统的磁盘操作活动。通过iostat方便查看CPU、网卡、tty设备、磁盘等设备的活动情况和负载信息。
命令：iostat [参数] [采样间隔时间秒数] [采样次数]
例如：
iostat -cm -d 2 10  -x   //监控CPU&磁盘的详细信息，2秒间隔总计10次
iostat -cm -d 2 10       //监控CPU&磁盘的简要信息，2秒间隔总计10次，会显示tps

iostat参数：
-c 显示CPU使用情况
-d 显示磁盘使用情况
-k 以 KB 为单位显示
-m 以 M 为单位显示
-N 显示磁盘阵列(LVM) 信息
-n 显示NFS 使用情况
-p[磁盘] 显示磁盘和分区的情况
-t 显示终端和CPU的信息
-x 显示详细信息
-V 显示版本信息

输出的常用属性值介绍

CPU属性值：
%user：CPU处在用户模式下的时间百分比。
%nice：CPU处在带nice值的用户模式下的时间百分比。
%system：CPU处在系统模式下的时间百分比。
%iowait：CPU等待输入输出完成时间的百分比。
%steal：管理程序维护另一个虚拟处理器时，虚拟CPU的无意识等待时间百分比。
%idle：CPU空闲（无IO请求处理）时间百分比。

说明：
1）如果%iowait的值过高，表示硬盘存在I/O瓶颈；
2）如果%idle的值过高，表示CPU较空闲；
3）如果%idle的值较高但系统响应慢时，有可能是CPU等待分配内存，此时应加大内存容量；
4）如果%idle的值持续低于10，那么系统的CPU处理能力相对较低，表明系统中最突出需要解决的资源是CPU。

TPS&吞吐量属性值：
tps：设备每秒的传输次数。一次传输是指一次I/O请求。多个逻辑请求可能会被合并为一次I/O请求。一次传输请求的大小是未知的。
kB_read/s：每秒从设备读取的数据量。
kB_wrtn/s：每秒向设备写入的数据量。
kB_read：读取的总数据量。
kB_wrtn：写入的总数量数据量。

磁盘属性值：
rrqm/s: 每秒进行merge的读操作数目。即rmerge/s。
wrqm/s: 每秒进行merge的写操作数目。即wmerge/s。
r/s: 每秒完成的读I/O设备次数。即rio/s。
w/s: 每秒完成的写I/O设备次数。即wio/s。
rsec/s: 每秒读扇区数。即rsect/s。
wsec/s: 每秒写扇区数。即wsect/s。
rkB/s: 每秒读K字节数。是rsect/s的一半，因为每扇区大小为512字节。
wkB/s: 每秒写K字节数。是wsect/s的一半。
avgrq-sz: 平均每次设备I/O操作的数据大小 (扇区)。
avgqu-sz: 平均I/O队列长度，相当于单位时间里平均排队的个数。
await: 平均每次设备I/O操作的等待时间 (毫秒)。
svctm: 平均每次设备I/O操作的服务时间 (毫秒)。
%util: 一秒中有百分之多少的时间用于I/O操作，即被IO消耗的cpu百分比。也可以理解为一秒中有多少时间I/O队列是非空的。

说明：
1）如果%util接近100%，说明产生的I/O请求太多，I/O系统已经满负荷，磁盘可能存在瓶颈；
   同时可以结合vmstat查看查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比，高过30%时IO压力较高)。
   注意：
   IOPS：IO per Second，IO系统每秒所执行IO操作的次数。
   IO的响应时间的增长是非线性的，IO越是接近最大值，响应时间就变得越大，而且会比预期超出很多。
   一般来说在实际的应用中有一个70%的指导值。也就是说在IO读写的队列中，当队列大小小于最大IOPS的70%的时候，IO的响应时间增加会很小，一般都能接受。
   一旦超过70%，响应时间就会戏剧性的暴增。
   所以当一个系统的IO压力超出最大可承受压力的70%的时候，就是必须要考虑优化或升级。
   这个70%的指导值也适用于CPU响应时间，实践中证明，一旦CPU超过70%，系统将会变得比较慢。

2）await一般要和svctm联合起来分析。
   await的大小一般取决于服务时间(svctm)以及I/O队列的长度和I/O请求的发出模式。
   svctm的大小一般和磁盘性能有关，CPU/内存的负荷也会对其有影响，请求过多也会间接导致svctm的增加。
   svctm一般要小于await，因为同时等待的请求的等待时间被重复计算了。
   如果svctm接近await，说明I/O几乎没有等待时间。
   如果await远大于svctm（差值较高），说明I/O队列太长，IO响应太慢，应用得到的响应时间太慢。如果用户不能容忍，则必须进行优化。可以考虑更换更快的磁盘、优化应用或升级CPU。
   
3）如果avgqu-sz较大，说明有大量的IO在等待。
   如果avgqu-sz较小，即使r/s+w/s很大，说明这些I/O请求比较均匀，大部分处理还是比较及时的。
   avgqu-sz × ( r/s or w/s ) = rsec/s or wsec/s。也就是说读写速度是这个来决定的。

[root@myoracle ~]# iostat -cdm 2 2  -x  
Linux 3.10.0-327.el7.x86_64 (myoracle)       03/27/2019      _x86_64_        (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.43    0.00    0.46    1.05    0.00   97.05

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.04     6.68    9.93  307.84     0.92    13.91    95.60     0.14    0.45    4.81    0.31   0.27   8.68
dm-0              0.00     0.00   10.08  314.52     0.92    13.91    93.58     0.17    0.51    4.87    0.38   0.27   8.66

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.75    0.00    2.98    9.25    0.00   83.02

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     0.00    0.00 4054.00     0.00   105.63    53.36     0.85    0.21    0.00    0.21   0.19  77.50
dm-0              0.00     0.00    0.00 4054.00     0.00   105.63    53.36     0.86    0.21    0.00    0.21   0.19  77.65

[root@myoracle ~]# iostat -cdm 2 2 
Linux 3.10.0-327.el7.x86_64 (myoracle)       03/27/2019      _x86_64_        (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.44    0.00    0.47    1.06    0.00   97.04

Device:            tps    MB_read/s    MB_wrtn/s    MB_read    MB_wrtn
sda             321.41         0.92        14.02       3485      53182
dm-0            328.23         0.92        14.02       3483      53182

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10.26    0.00    4.43    8.99    0.00   76.31

Device:            tps    MB_read/s    MB_wrtn/s    MB_read    MB_wrtn
sda            3847.00         0.00       140.00          0        280
dm-0           3847.00         0.00       140.00          0        280

2.vmstat
vmstat是Virtual Meomory Statistics（虚拟内存统计）的缩写，可对操作系统的虚拟内存、进程、IO读写、CPU活动等进行监视。
它是对系统的整体情况进行统计，不足之处是无法对某个进程进行深入分析。

# vmstat -S M 
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0    102    202      0   7331    0    0    38   664   90  119  1  0 99  0  0

--procs--
r：等待运行的进程数。如果等待运行的进程数越多，意味着CPU非常繁忙。另外，如果该参数长期大于和等于逻辑cpu个数，则CPU资源可能存在较大的瓶颈。
b：处在非中断睡眠状态(in uninterruptible sleep)的进程数。意味着进程被阻塞。主要是指被资源阻塞的进程对列数（比如：IO资源、页面调度等）。当这个值较大时，需要根据应用程序来分析。例如：数据库产品等。
--memory--
swapd：已使用的虚拟内存大小。如果虚拟内存使用较多，可能系统物理内存比较吃紧，需要优化减少物理内存的使用或增加物理内存。swapd不为0时，也并不意味物理内存吃紧；如果swapd无变化、si、so的值长期为0，也是正常的。
free：空闲的物理内存的大小。
buff：buffer内存数（KB）
cache：cache内存数（KB）
--swap--
si：从磁盘交换到swap虚拟内存的交换页数量（KB/秒）。
so：从swap虚拟内存交换到磁盘的交换页数量（KB/秒）。

--io--
bi：每秒从块设备接收到的块数（块/秒），也就是读块设备。
bo：每秒发送到块设备的块数（块/秒），也就是写块设备。
--system--
in：每秒的中断数，包括时钟中断。
cs：每秒的环境（上下文）切换次数。注意：过多的上下文切换会浪费较多的cpu资源，该值应该越小越好。
--cpu--
us：用户CPU时间(非内核进程占用时间)（单位为百分比）。us的值越高说明用户进程消耗的CPU时间多。
sy：系统使用的CPU时间（单位为百分比）。该值高时，说明系统内核消耗的CPU资源多，此时需要检查原因。
id：空闲的CPU的时间(百分比)。
wa：等待IO的CPU时间。
st：针对虚拟技术，如果st不为0，说明本来分配给本机的CPU时间被其他虚拟机偷走了。

说明：
1）物理内存够用时，si和so一般长期为0。如果这个值大于0，表示物理内存不够用或者内存泄露了。
   swap交换会影响系统性能，会消耗磁盘IO和CPU资源。
   不过如果这两个值虽然大于0、但值很小，其实对系统性能影响也不大。

2）如果物理空闲内存（free）很少的或接近于0时，不能仅凭这个值判断为物理内存不够用。还要结合si和so来判断，如果si和so长期为0或很小，内存也够用，系统性能此时基本不会受到影响。

3.ifstat
ifstat是个网络接口监测工具，可以方便的查看网络流量信息。
命令：ifstat [interfaceName]

# ifstat  eth0
#kernel
Interface        RX Pkts/Rate    TX Pkts/Rate    RX Data/Rate    TX Data/Rate  
                 RX Errs/Drop    TX Errs/Drop    RX Over/Rate    TX Coll/Rate  
eno16777984       178728 0         11014 0       270412K 0        729576 0      
                       0 0             0 0             0 0             0 0 

4.iftop
iftop是一款实时流量监控工具，监控TCP/IP连接等，必须以root身份才能运行。
iftop -i eth0 
通过iftop的界面很容易找到哪个ip在网络流量占用情况，流量单位是Mb，这个和ifstat的KB有区别。

5.iotop
查看哪个进程使用硬盘最多的最简单的方法就是使用iotop命令。

6.top
这里重点关注load average、us、wa参数。
load average：CPU load（平均负载）是指上一分钟同时处于就绪状态的平均进程数。这是评估一个是繁忙的重要指标。
  它所包含的信息不是CPU的使用率状况，而是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息。也就是CPU使用队列的长度的统计信息。
  uptime、top命令中都可以看到load average。它显示了一分钟、五分钟、以及十五分钟的系统平均负载。
  在CPU中可以理解为：CPU可以并行处理的任务数量 = CPU个数 * 核数。
  如果CPU Load等于CPU个数 * 核数，那么就说明CPU正好满负载了；如果再多，有些任务不能被及时分配处理器。如果要保证性能的话，理想的值要小于CPU个数 * 核数 * 0.7，即CPU满载的70%。
  单核的机器：
  load=0.5，则表示CPU还有一半的资源可以处理其他的线程请求；
  load=1，则表示CPU所有的资源都在处理请求，没有剩余的资源可以利用了；
  load=2，则表示CPU已经超负荷运作，另外还有一倍的线程正在等待处理。
  因此，单核的机器，load值要小于1，为了保证性能，理想的值是0.7；双核机器：load要小于2，理想值是1.4；多核处理器中，值不应该高于处理器核的总数量，理想值为总数量*0.7。
us：CPU处在用户模式下的时间百分比。
sy：CPU处在系统模式下的时间百分比。
id：空闲的cpu时间比。
    如果该值持续为0，同时sy是us的两倍，则通常说明系统面临着CPU资源的短缺。
wa：CPU等待IO完成的时间的百分比。这个数字越高，说明CPU资源浪费在等待I/O权限。
    如果us和sy不高、但wa很高，如果被测服务是磁盘IO密集型服务，wa高可能属于正常现象。
    但如果不是磁盘IO密集型服务，通常可能导致wa高的原因有下面两个：
    一是服务对磁盘读写的业务逻辑有问题，读写频率过高，写入数据量过大。例如：不合理的数据载入策略，应用写日志过多等。
    二是服务器内存不足，涉及到swap分区使用，si&so加高，不停的和磁盘交换数据。
hi：硬中断消耗时间。
si：软终端消耗的时间。
st：虚拟机偷走的时间。

#top信息
top - 14:40:12 up  4:47,  4 users,  load average: 0.99, 0.41, 0.21
Tasks: 227 total,   2 running, 225 sleeping,   0 stopped,   0 zombie
%Cpu0  :  9.3 us,  3.3 sy,  0.0 ni, 78.7 id,  8.7 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  : 12.3 us,  3.7 sy,  0.0 ni, 77.3 id,  6.0 wa,  0.0 hi,  0.7 si,  0.0 st
%Cpu2  : 10.7 us,  2.3 sy,  0.0 ni, 84.6 id,  1.7 wa,  0.0 hi,  0.7 si,  0.0 st
%Cpu3  : 11.0 us,  2.0 sy,  0.0 ni, 86.0 id,  0.7 wa,  0.0 hi,  0.3 si,  0.0 st
%Cpu4  : 10.7 us,  2.3 sy,  0.0 ni, 85.9 id,  0.7 wa,  0.0 hi,  0.3 si,  0.0 st
%Cpu5  : 12.1 us,  3.0 sy,  0.0 ni, 82.8 id,  1.0 wa,  0.0 hi,  1.0 si,  0.0 st
%Cpu6  : 11.6 us, 12.6 sy,  0.0 ni, 18.6 id, 56.5 wa,  0.0 hi,  0.7 si,  0.0 st
%Cpu7  : 10.7 us,  2.7 sy,  0.0 ni, 83.6 id,  2.3 wa,  0.0 hi,  0.7 si,  0.0 st
KiB Mem :  8175588 total,   151708 free,   513252 used,  7510628 buff/cache
KiB Swap:  8191996 total,  8082240 free,   109756 used.  5350944 avail Mem 

关于CPU负载的正确理解：
1）load高，不一定是性能有问题，也许是因为在进行cpu密集型的计算。
2）load高，也不一定是CPU能力问题或CPU数量不够，也许是因为I/O问题或其他问题导致。
3）如果load长期持续较高，需要定位优化，但不是简单的增加CPU。增加CPU可能治标不治本。
4）load持续偏高，需要定位根本原因：CPU不足/IO瓶颈/内存不足/其他设备瓶颈/应用程序代码BUG

7.lsof
查找哪个文件引起的I/O wait。lsof命令可以展示一个进程打开的所有文件，或者打开一个文件的所有进程。
从打印的列表中，可以找到具体是什么文件被写入，根据文件的大小和/proc目录中IO文件的具体数据，可以使用-p <pid>的方式来减少输出。