iostat centos？centos 7.9

解决centos7.2中磁盘iowait过高(centos7启动后盘符错位问题)

（一）简述

每天都收到磁盘iowait告警信息，尤其是日志服务器在进行大量的读写操作过程中，从而造成系统处于崩溃边缘，为查找磁盘iowait由于什么原因造成的以及后续的系统的优化点。centos有许多查找问题的工具，也有高级的。

I/O Wait就是一个需要使用高级的工具来debug的问题，当然也有许多基本工具的高级用法。I/O wait的问题难以定位的原因是因为我们有很多工具可以告诉你说I/O受限了，但是并没有告诉你具体是哪些进程们引起的。

具体的思路如下：top。查看由cpu一行浪费在iowait上的cpu百分比=iostat-x 2 5查看某块磁盘正在被写入= iotop查找最高的磁盘I/O对应的进程= lsof-p pid查看通过一个进程打开所有文件或打开一个文件的所有进程。

（二）具体步骤如下：

（1）通过top命令来确认是否是I/O导致系统缓慢。

[root@iZ23iod5vslZ~]# toptop- 15:38:32 up 40 days, 5:59, 3 users, load average: 0.00, 0.01, 0.05Tasks: 128 total, 1 running, 127 sleeping, 0 stopped, 0 zombieCpu(s): 0.4 us, 0.2 sy, 0.0 ni, 99.2 id, 98 wa, 0.0 hi, 0.0 si, 0.1 stKiB Mem: 32520424 total, 31492136 used, 1028288 free, 412772 buffersKiB Swap: 0 total, 0 used, 0 free. 25902892 cached Mem PID USER PR NI VIRT RES SHR S CPU MEM TIME+ COMMAND 18988 root 20 0 11.647g 3.611g 7896 S 2.7 11.6 507:57.30 java 28 root 20 0 0 0 0 S 0.3 0.0 6:43.31 rcuos/3 1 root 20 0 49556 3412 1912 S 0.0 0.0 0:14.60 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kthreadd 3 root 20 0 0 0 0 S 0.0 0.0 0:48.28 ksoftirqd/0 5 root 0-20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H 7 root rt 0 0 0 0 S 0.0 0.0 0:00.83 migration/0 8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh 9 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcuob/0 10 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcuob/1 11 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcuob/2 12 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcuob/3 13 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcuob/4 14 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcuob/5 15 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcuob/6 16 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcuob/7

从Cpu一行我们可以看到浪费在I/O Wait上的CPU百分比；这个数字越高说明越多的CPU资源在等待I/O权限.具体的解释如下：

0.4 us用户空间占用CPU的百分比。

0.2 sy内核空间占用CPU的百分比。

0.0 ni改变过优先级的进程占用CPU的百分比

2 id空闲CPU百分比

98 wa IO等待占用CPU的百分比

0.0 hi硬中断（Hardware IRQ）占用CPU的百分比

0.0 si软中断（Software Interrupts）占用CPU的百分比

在这里CPU的使用比率和windows概念不同，如果你不理解用户空间和内核空间，需要充充电了

（2）通过iostat-x 3 3查看那块磁盘正在被写入。

[root@iZ23iod5vslZ~]# iostat-x 3 3Linux 3.10.0-123.9.3.el7.x86_64(iZ23iod5vslZ) 08/14/2017 _x86_64_(4 CPU)avg-cpu: user nice system iowait steal idle 0.70 0.00 0.16 0.75 0.05 98.34Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm utilxvda 0.00 21.18 0.32 18.33 9.94 195.06 21.98 0.08 4.11 11.44 3.98 1.54 2.88xvdb 0.00 15.21 1.23 1.98 38.41 68.76 66.70 0.08 25.48 3.59 39.10 1.09 0.35xvdc 0.00 0.07 0.00 0.91 0.00 36.25 79.43 0.10 106.88 12.53 106.92 1.33 0.12avg-cpu: user nice system iowait steal idle 0.75 0.00 0.17 0.08 0.08 98.91Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm utilxvda 0.00 2.33 0.00 0.67 0.00 12.00 36.00 0.00 5.50 0.00 5.50 5.50 0.37xvdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00xvdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00avg-cpu: user nice system iowait steal idle 0.75 0.00 0.17 0.00 0.00 99.08Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm utilxvda 0.00 3.33 0.00 1.67 0.00 34.67 41.60 0.01 3.00 0.00 3.00 1.60 100.27xvdb 0.00 9.00 0.00 1.67 0.00 42.67 51.20 0.01 5.40 0.00 5.40 1.80 0.30xvdc 0.00 0.33 0.00 0.67 0.00 4.00 12.00 0.00 2.00 0.00 2.00 2.00 0.13

每隔三秒更新一次，一共打印了三次。-x时打印出扩展选项。第一次打印的信息可以被忽略，剩下的报告，都是基于上一次间隔的时间打印出来。

上述的列子中xvda的 util（利用率）是100.27,有进程往磁盘中写入数据。

（3）通过iotop查找高I/O对应的进程

[root@iZ23iod5vslZ~]# iotopTotal DISK READ: 0.00 B/s| Total DISK WRITE: 15.67 K/sActual DISK READ: 0.00 B/s| Actual DISK WRITE: 0.00 B/s TID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND 18793 be/4 root 0.00 B/s 3.92 K/s 0.00 0.00 java-Djava.util.logging.config.file=/usr/to~p org.apache.catalina.startup.Bootstrap start18987 be/4 root 0.00 B/s 3.92 K/s 0.00 0.00 cronolog/guojinbao/tomcat/logs/catalina.Y-m-d.out18796 be/4 root 0.00 B/s 3.92 K/s 0.00 0.00 java-Djava.util.logging.config.file=/usr/to~p org.apache.catalina.startup.Bootstrap start13193 be/4 root 0.00 B/s 3.92 K/s 0.00 0.00 java-Djava.util.logging.config.file=/usr/to~p org.apache.catalina.startup.Bootstrap start 1 be/4 root 0.00 B/s 0.00 B/s 0.00 0.00 systemd--switched-root--system--deserialize 22 2 be/4 root 0.00 B/s 0.00 B/s 0.00 0.00 [kthreadd] 3 be/4 root 0.00 B/s 0.00 B/s 0.00 0.00 [ksoftirqd/0]16388 be/4 root 0.00 B/s 0.00 B/s 0.00 0.00 AliYunDun 5 be/0 root 0.00 B/s 0.00 B/s 0.00 0.00 [kworker/0:0H]16390 be/4 root 0.00 B/s 0.00 B/s 0.00 0.00 AliYunDun 7 rt/4 root 0.00 B/s 0.00 B/s 0.00 0.00 [migration/0] 8 be/4 root 0.00 B/s 0.00 B/s 0.00 0.00 [rcu_bh] 9 be/4 root 0.00 B/s 0.00 B/s 0.00 0.00 [rcuob/0] 10 be/4 root 0.00 B/s 0.00 B/s 0.00 0.00 [rcuob/1] 11 be/4 root 0.00 B/s 0.00 B/s 0.00 0.00 [rcuob/2]

从上述的例子中可以看出进程号为cronolog18987占用了大量的磁盘IO

（4）通过lsof-p pid查找由那个文件引起的IOwait

[root@iZ23iod5vslZ~]# lsof-p 18987COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAMEcronolog 18987 root cwd DIR 202,17 20480 2400258/guojinbao/tomcat/logscronolog 18987 root rtd DIR 202,1 4096 2/cronolog 18987 root txt REG 202,1 48627 152798/usr/local/sbin/cronologcronolog 18987 root mem REG 202,1 2107600 132826/usr/lib64/libc-2.17.socronolog 18987 root mem REG 202,1 160240 132819/usr/lib64/ld-2.17.socronolog 18987 root 0r FIFO 0,8 0t0 42614018 pipecronolog 18987 root 1w CHR 1,3 0t0 1028/dev/nullcronolog 18987 root 2u CHR 136,0 0t0 3/dev/pts/0(deleted)cronolog 18987 root 3w REG 202,17 5704875979 2400280/guojinbao/tomcat/logs/catalina.2017-08-14.out

lsof命令可以展示一个进程打开的所有文件，或者打开一个文件的所有进程。从这个列表中，我们可以找到具体是什么文件被写入，根据文件的大小和/proc中io文件的具体数据.

为了确认我们的怀疑，我们可以使用/proc文件系统，每个进程目录下都有一个叫io的文件，里边保存这和iotop类似的信息

[root@iZ23iod5vslZ~]# cat/proc/18987/io rchar: 58891582418wchar: 58891579778syscr: 46556085syscw: 46556077read_bytes: 212992write_bytes: 59580235776cancelled_write_bytes: 0

read_bytes和write_bytes是这个进程从磁盘读写的字节数。这个例子中cronolog读取了212992byte（0.2M）数据，写入了59580235776bytes（55.4G）数据到磁盘上。

（5）通过df-h/guojinbao来查看服务器那块磁盘的根目录

[root@iZ23iod5vslZ~]# df-h/guojinbao/Filesystem Size Used Avail Use Mounted on/dev/xvdb1 45G 38G 4.7G 89/guojinbao

最后,通过以上的信息我们可以放心的说lsof的结果就是我们要查找的文件

在Linux 中如何使用 iotop 和 iostat 监控磁盘 I/O 活动

在 Linux中监控磁盘 I/O活动的工具包括 iotop和 iostat。iotop类似于 top命令，但专门用于显示实时的磁盘活动。它通过监控内核输出的 I/O使用信息，显示系统中进程或线程的当前 I/O使用情况。iotop显示每个进程/线程的读写 I/O带宽，以及等待 I/O的线程/进程所花费时间的百分比。iotop还显示了总 I/O带宽和实际磁盘 I/O带宽。

要安装 iotop，可以使用包管理器，具体取决于您的 Linux发行版。例如，对于 Fedora系统，可以使用 DNF命令安装。对于 Debian/Ubuntu系统，可以使用 API-GET或 APT命令安装。基于 Arch Linux的系统可以使用 Pacman Command安装，RHEL/CentOS的系统则使用 YUM Command，openSUSE Leap的系统则使用 Zypper Command。

iotop命令有许多参数，可以用来检查磁盘 I/O的变化。例如，可以通过运行带有-o或--only参数的 iotop命令来检查实际执行 I/O的进程。要监控所有设备的 I/O统计，可以使用带有-d参数的 iostat命令。若要查看所有设备和分区的统计信息，可以使用带有-p参数的 iostat命令。要查看具体设备和分区的详细 I/O统计信息，可以使用带有-x参数的 iostat命令。

iostat命令是 sysstat包的一部分，该工具用于报告中央处理单元（CPU）的统计和设备与分区的输出/输入统计。iostat通过观察设备活跃时间的平均传输率来监控系统输入/输出设备负载。在多处理器系统中，CPU统计是系统层面所有处理器的平均值。iostat命令可以生成两种类型的报告：CPU利用率报告和设备利用率报告。

要安装 iostat，同样可以使用包管理器。例如，对于 Fedora系统，可以使用 DNF Command安装 sysstat。对于 Debian/Ubuntu系统，可以使用 APT-GET Command或 APT Command安装。基于 Arch Linux的系统使用 Pacman Command，RHEL/CentOS的系统使用 YUM Command，而 openSUSE Leap的系统则使用 Zypper Command。

iostat命令提供了多种参数，以检查 I/O和 CPU变化的统计信息。不加参数运行 iostat命令会显示完整的系统统计信息。使用带有-d参数的 iostat命令可以查看所有设备的 I/O统计信息。使用带有-p参数的 iostat命令可以查看所有设备和分区的 I/O统计信息。使用带有-x参数的 iostat命令可以显示所有设备的详细 I/O统计信息。使用带有-d [设备名]参数的 iostat命令可以查看特定设备及其分区的 I/O统计信息。使用带有-m参数的 iostat命令可以查看以 MB为单位的设备统计信息，默认以 KB显示输出。使用带有-N参数的 iostat命令可以查看 LVM磁盘 I/O统计报告。此外，可以使用 nfsiostat命令查看 NFS的 I/O统计。

CentOS系统中跟踪高IO等待详解

高IO等待问题的第一个征兆通常是系统平均负载。负载均衡的计算都是基于CPU利用率的，即使用或等待CPU的进程数目，当然，在Linux平台上，进程几乎都处于不可中断的睡眠状态。负载均衡的基线可以解释为，在一个CPU核的机器上上，该CPU得到充分利用。因此，对于4核机器中，如果系统平均复杂为 4，表示该机器有足够的资源来处理它需要做的工作，当然只是勉强。在相同的4核系统，如果平均复杂是8，那么以为这将意味着服务器系统需要8个core才能处理所要做的工作，但现在只有4个核，所以已经超载。

如果系统显示平均负载较高，但是CPU的系统(system)和用户(user)利用率较低，那么就需要观察IO等待(即IO wait)。在linuc系统上，IO wait对系统负载有较大的影响，主要因为一个或多个核都可能被磁盘IO或网络

发现进程在等待IO完成是一回事，验证高IO wait的原因是另一回事。使用”iostat–x 1”能够显示正在使用的物理存储设备的IO情况：

[username@server~]$ iostat-x 1

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm%util

cciss/c0d0 0.08 5.94 1.28 2.75 17.34 69.52 21.60 0.11 26.82 4.12 1.66

cciss/c0d0p1 0.00 0.00 0.00 0.00 0.00 0.00 5.30 0.00 8.76 5.98 0.00

cciss/c0d0p2 0.00 0.00 0.00 0.00 0.00 0.00 58.45 0.00 7.79 3.21 0.00

cciss/c0d0p3 0.08 5.94 1.28 2.75 17.34 69.52 21.60 0.11 26.82 4.12 1.66

由上可知，很明显，设备/dev/cciss/c0d0p3的等待时间很长。然而，我们并没有挂载找个设备，实际上，它是个LVM设备。如果您使用的是 LVM作为存储，那么，您应该发现iostat应该有那么一点混乱。LVM使用device mapper子系统将文件系统映射到物理设备，因此，iostat可能显示多个设备，比如/ dev/dm-0和/ dev/dm-1。而”df–h”的输出却不会显示device mapper路径，而是打印了LVM路径。最简单的方法是在iostat参数中添加选项”-N”。

[username@server~]$ iostat-xN 1

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm%util

vg1-root 0.00 0.00 0.09 3.01 0.85 24.08 8.05 0.08 24.69 1.79 0.55

vg1-home 0.00 0.00 0.05 1.46 0.97 11.69 8.36 0.03 19.89 3.76 0.57

vg1-opt 0.00 0.00 0.03 1.56 0.46 12.48 8.12 0.05 29.89 3.53 0.56

vg1-tmp 0.00 0.00 0.00 0.06 0.00 0.45 8.00 0.00 24.85 4.90 0.03

vg1-usr 0.00 0.00 0.63 1.41 5.85 11.28 8.38 0.07 32.48 3.11 0.63

vg1-var 0.00 0.00 0.55 1.19 9.21 9.54 10.74 0.04 24.10 4.24 0.74

vg1-swaplv 0.00 0.00 0.00 0.00 0.00 0.00 8.00 0.00 3.98 1.88 0.00

为简便起见，裁剪上面iostat命令的输出信息。列出的每个文件系统所显示出的IO等待都是不可接受的，观察第十栏标有“await”的数据。相比而言，文件系统/usr的await时间要高一些。我们先来分析一下这个文件系统，使用命令” fuser-vm/opt”查看哪些进程在访问这个文件系统，进程列表如下。

root@server:/root> fuser-vm/opt

USER PID ACCESS COMMAND

/opt: db2fenc1 1067....m db2fmp

db2fenc1 1071....m db2fmp

db2fenc1 2560....m db2fmp

db2fenc1 5221....m db2fmp

当前服务器上有112个DB2进程正在访问/opt文件系统，为简便起见，列出四项。看来已经找到导致问题的原因，在服务器上，数据库配置为可使用速度更快的SAN访问，操作系统可以使用的是本地磁盘。可以打电话问问DBA(数据库管理员)怎么做才能这样配置。

最后一个组要的注意的是LVM和device mapper。“Iostat–xN”命令的输出显示的是逻辑卷名，但它是可以通过命令”ls–lrt/ dev/mapper”查到映射关系表。输出信息的第六列中的dm-是与iostat中的设备名相对应的。

有时候，在操作系统或应用层是没有什么可以做的，除了选择速度更快的磁盘，并没有其他的选择。幸运的是，快速磁盘访问，如SAN或SSD的价格正在逐步下降。