Linux 有许多可用来查找问题的简单工具，也有许多是更高级的
I/O Wait 就是一个需要使用高级的工具来debug的问题，当然也有许多基本工具的高级用法。I/O wait的问题难以定位的原因是因为我们有很多工具可以告诉你说I/O 受限了，但是并没有告诉你具体是那个进程引起的（哪些进程们）
确认是否是I/O问题导致系统缓慢
确认是否是I/O导致的系统缓慢我们可以使用多个命令，但是，最简单的是unix的命令 top
[root@localhost ~]# top top - 15:19:26 up 6:10, 4 users, load average: 0.00, 0.01, 0.05 Tasks: 147 total, 1 running, 146 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.0 us, 0.3 sy, 0.0 ni, 99.7 id, 96.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 999936 total, 121588 free, 328672 used, 549676 buff/cache KiB Swap: 2097148 total, 2095792 free, 1356 used. 450460 avail Mem
从Cpu一行我们可以看到浪费在I/O Wait上的CPU百分比；这个数字越高说明越多的CPU资源在等待I/O权限
wa -- iowait AmountoftimetheCPUhasbeenwaitingfor I/O to complete.
查找哪块磁盘正在被写入
上边的top命令从一个整体上说明了I/O wait，但是并没有说明是哪块磁盘影响的，想知道是哪块磁盘引发的问题，我们用到了另外一个命令 iostat 命令
[root@localhost ~]# iostat -x 2 5
Linux 3.10.0-514.el7.x86_64 (localhost.localdomain) 2017年03月03日 _x86_64_ (1 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.34 0.00 0.31 0.01 0.00 99.33
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.05 1.16 0.17 39.00 17.38 84.60 0.00 2.17 0.87 11.14 0.65 111.41
scd0 0.00 0.00 0.00 0.00 0.00 0.00 8.00 0.00 0.64 0.64 0.00 0.64 0.00
dm-0 0.00 0.00 1.10 0.20 37.85 17.21 84.71 0.00 2.43 0.90 10.88 0.66 0.09
dm-1 0.00 0.00 0.01 0.02 0.07 0.08 9.70 0.00 1.42 0.27 2.05 0.09 0.00
上边的例子中，iostat 会每2秒更新一次，一共打印5次信息， -x 的选项是打印出扩展信息
第一个iostat 报告会打印出系统最后一次启动后的统计信息，这也就是说，在多数情况下，第一个打印出来的信息应该被忽略，剩下的报告，都是基于上一次间隔的时间。举例子来说，这个命令会打印5次，第二次的报告是从第一次报告出来一个后的统计信息，第三次是基于第二次 ，依次类推
在上面的例子中，sda的%utilized 是111.41%，这个很好的说明了有进程正在写入到sda磁盘中。
除了%utilized 外，我们可以得到更丰富的资源从iostat，例如每毫秒读写请求（rrqm/s & wrqm/s)），每秒读写的（(r/s & w/s)，当然还有更多。在上边的例子中，我们的项目看起来正在读写非常多的信息。这个对我们查找相应的进程非常有用
查找引起高I/O wait 对应的进程
[root@localhost ~]# iotop Total DISK READ : 0.00 B/s | Total DISK WRITE : 0.00 B/s Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 0.00 B/s TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND 1028 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % sshd
最简单的方式来发现罪魁祸首是使用命令iotop，通过查看iotop的统计信息，我们可以很容易的指导sshd就是罪魁祸首
虽然iotop是一个非常强大的工具，并且使用简单，但是它并不是默认安装在所有的linux操作系统中。并且我个人倾向不要太依赖那些默认没有安装的命令。一个系统管理员可能会发现他无法立即安装额外的除默认程序之外的软件，除非等到后边的维护的时间。
查找哪个文件引起的I/Owait
lsof 命令可以展示一个进程打开的所有文件，或者打开一个文件的所有进程。从这个列表中，我们可以找到具体是什么文件被写入，根据文件的大小和/proc中io文件的具体数据
我们可以使用-p <pid>的方式来减少输出，pid是具体的进程
[root@localhost ~]# lsof -p 1028 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME sshd 1028 root cwd DIR 253,0 233 64 / sshd 1028 root rtd DIR 253,0 233 64 / sshd 1028 root txt REG 253,0 819640 2393730 /usr/sbin/sshd sshd 1028 root mem REG 253,0 61752 180464 /usr/lib64/libnss_files-2.17.so sshd 1028 root mem REG 253,0 43928 180476 /usr/lib64/librt-2.17.so sshd 1028 root mem REG 253,0 15688 269136 /usr/lib64/libkeyutils.so.1.5 sshd 1028 root mem REG 253,0 62744 482870 /usr/lib64/libkrb5support.so.0.1 sshd 1028 root mem REG 253,0 11384 180425 /usr/lib64/libfreebl3.so sshd 1028 root mem REG 253,0 143352 180472 /usr/lib64/libpthread-2.17.so sshd 1028 root mem REG 253,0 251784 202440 /usr/lib64/libnspr4.so sshd 1028 root mem REG 253,0 20016 202441 /usr/lib64/libplc4.so sshd 1028 root mem REG 253,0 15768 202442 /usr/lib64/libplds4.so sshd 1028 root mem REG 253,0 182056 202443 /usr/lib64/libnssutil3.so sshd 1028 root mem REG 253,0 1220240 650074 /usr/lib64/libnss3.so sshd 1028 root mem REG 253,0 164048 650076 /usr/lib64/libsmime3.so sshd 1028 root mem REG 253,0 276752 650077 /usr/lib64/libssl3.so sshd 1028 root mem REG 253,0 121296 269112 /usr/lib64/libsasl2.so.3.0.0 sshd 1028 root mem REG 253,0 398264 202404 /usr/lib64/libpcre.so.1.2.0 sshd 1028 root mem REG 253,0 2116736 180446 /usr/lib64/libc-2.17.so sshd 1028 root mem REG 253,0 15848 202439 /usr/lib64/libcom_err.so.2.1 sshd 1028 root mem REG 253,0 202568 482862 /usr/lib64/libk5crypto.so.3.1 sshd 1028 root mem REG 253,0 959008 482868 /usr/lib64/libkrb5.so.3.3 sshd 1028 root mem REG 253,0 324888 482858 /usr/lib64/libgssapi_krb5.so.2.2 sshd 1028 root mem REG 253,0 110632 180474 /usr/lib64/libresolv-2.17.so sshd 1028 root mem REG 253,0 40640 180450 /usr/lib64/libcrypt-2.17.so sshd 1028 root mem REG 253,0 113152 180456 /usr/lib64/libnsl-2.17.so sshd 1028 root mem REG 253,0 90664 202424 /usr/lib64/libz.so.1.2.7 sshd 1028 root mem REG 253,0 14432 186432 /usr/lib64/libutil-2.17.so sshd 1028 root mem REG 253,0 61872 766946 /usr/lib64/liblber-2.4.so.2.10.3 sshd 1028 root mem REG 253,0 344280 766948 /usr/lib64/libldap-2.4.so.2.10.3 sshd 1028 root mem REG 253,0 19344 180452 /usr/lib64/libdl-2.17.so sshd 1028 root mem REG 253,0 2025472 482880 /usr/lib64/libcrypto.so.1.0.1e sshd 1028 root mem REG 253,0 23968 202508 /usr/lib64/libcap-ng.so.0.0.0 sshd 1028 root mem REG 253,0 155744 202421 /usr/lib64/libselinux.so.1 sshd 1028 root mem REG 253,0 61672 539049 /usr/lib64/libpam.so.0.83.1 sshd 1028 root mem REG 253,0 122936 202512 /usr/lib64/libaudit.so.1.0.0 sshd 1028 root mem REG 253,0 42520 298848 /usr/lib64/libwrap.so.0.7.6 sshd 1028 root mem REG 253,0 11328 568388 /usr/lib64/libfipscheck.so.1.2.1 sshd 1028 root mem REG 253,0 155064 180439 /usr/lib64/ld-2.17.so sshd 1028 root 0u CHR 1,3 0t0 5930 /dev/null sshd 1028 root 1u CHR 1,3 0t0 5930 /dev/null sshd 1028 root 2u CHR 1,3 0t0 5930 /dev/null sshd 1028 root 3u IPv4 21185 0t0 TCP *:ssh (LISTEN) sshd 1028 root 4u IPv6 21194 0t0 TCP *:ssh (LISTEN)
为了更深入的确认这些文件被频繁的读写，我们可以通过如下命令来查看
[root@localhost ~]# df /tmp 文件系统 1K-块 已用 可用 已用% 挂载点 /dev/mapper/cl-root 17811456 3981928 13829528 23% /
从上面的命令结果来看，我们可以确定/tmp 是我们环境的逻辑磁盘的根目录
[root@localhost ~]# pvdisplay --- Physical volume --- PV Name /dev/sda2 VG Name cl PV Size 19.00 GiB / not usable 3.00 MiB Allocatable yes (but full) PE Size 4.00 MiB Total PE 4863 Free PE 0 Allocated PE 4863 PV UUID 4QfaOy-DNSO-niK1-ayn2-K6AY-WZMy-9Nd2It
过pvdisplay我们能看到/dev/sda2其实就是我们用来创建逻辑磁盘的具体磁盘。通过以上的信息我们可以放心的说lsof的结果就是我们要查找的文件