在linux 上 磁盘读写过高 的 I/O 问题 导致 cpu wait 问题，这里是用一些方法找出问题。
首先 使用 top 命令找出 出现 cpu 中 是否进程运行等待问题
＃ top
-
top - 03: 57: 39 up 1 day, 15: 40, 0 users, load average: 0.00, 0.00, 0.00
-
Tasks: 8 total, 1 running, 7 sleeping, 0 stopped, 0 zombie
-
%Cpu(s): 0.0 us, 0.0 sy, 0.0 ni, 100.0 id, 95.1 wa, 0.0 hi, 0.0 si, 0.0 st
-
KiB Mem : 1019664 total, 174644 free, 78960 used, 766060 buff/cache
-
KiB Swap: 1165316 total, 1154816 free, 10500 used. 272848 avail Mem
在％Cpu(s) 一行中 95.1 wa (例子数据)
表示cpu 中出现严重等待问题，可能导致的原因就包括 读写磁盘 I/O 造成的
查找是否是 (确定 上面假设)I／O阻塞问题
方法有二
方法一
-
$ iostat -x 2 5
-
avg-cpu: %user %nice %system %iowait %steal %idle
-
3.66 0.00 47.64 48.69 0.00 0.00
-
-
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 44.50 39.27 117.28 29.32 11220.94 13126.70 332.17 65.77 462.79 9.80 2274.71 7.60 111.41
-
dm -0 0.00 0.00 83.25 9.95 10515.18 4295.29 317.84 57.01 648.54 16.73 5935.79 11.48 107.02
-
dm -1 0.00 0.00 57.07 40.84 228.27 163.35 8.00 93.84 979.61 13.94 2329.08 10.93 107.02
上面的指标 有有三个需要明白
%util 111.41 利用率，说明了磁盘 的 读写io 过高了，出现了延迟状况
await 响应时间 svctm 表示平均每次设备I/O操作的服务时间 await 和 svctm 越接近表示几乎没有I/O等待，上面差距大
r/s 117.28 读出请求数 w/s 29.32 写入请求数 说明读出次数过高
其它参数
-
rrqm/s：每秒这个设备相关的读取请求有多少被Merge了（当系统调用需要读取数据的时候，VFS将请求发到各个FS，如果FS发现不同的读取请求读取的是相同Block的数据，FS会将这个请求合并Merge）；wrqm/s：每秒这个设备相关的写入请求有多少被Merge了。
-
-
rsec/s：每秒读取的扇区数；
-
wsec/：每秒写入的扇区数。
-
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 平均请求扇区的大小
-
avgqu-sz 是平均请求队列的长度。毫无疑问，队列长度越短越好。
-
await： 每一个IO请求的处理的平均时间（单位是微秒毫秒）。这里可以理解为IO的响应时间，一般地系统IO响应时间应该低于 5ms，如果大于 10ms就比较大了。
-
这个时间包括了队列时间和服务时间，也就是说，一般情况下，await大于svctm，它们的差值越小，则说明队列时间越短，反之差值越大，队列时间越长，说明系统出了问题。
-
svctm 表示平均每次设备I/O操作的服务时间（以毫秒为单位）。如果svctm的值与await很接近，表示几乎没有I/O等待，磁盘性能很好，如果await的值远高于svctm的值，则表示I/O队列等待太长， 系统上运行的应用程序将变慢。
-
%util： 在统计时间内所有处理IO时间，除以总共统计时间。例如，如果统计间隔 1秒，该设备有 0.8秒在处理IO，而 0.2秒闲置，那么该设备的%util = 0.8/ 1 = 80%，所以该参数暗示了设备的繁忙程度
-
。一般地，如果该参数是 100%表示设备已经接近满负荷运行了（当然如果是多磁盘，即使%util是 100%，因为磁盘的并发能力，所以磁盘使用未必就到了瓶颈）。
方法二
-
root@ 50e261fb9e06:/var
-
-dsk/total-
-
read writ
-
1081B 977B
-
0 0
-
0 0
-
0 0
-
0 0
现在确定了 是 I／O 问题了，接着找出哪个进程 操作哪些文件而导致上面的原因的
同样提供两种方法
第一种 根据 linux IO 读写 epoll 机制（省略，研究中...)读写时会合理运用资源，就是某某进程在读资源，就会先sleep 一会，把cpu让给其他进程，那么阻塞的时候就会不间断的sleep 或 ps 里面 的 状态或“D”状态，所以可以用脚本找出如下可疑进程
-
-
D 248 [jbd2/dm -0 -8]
-
D 16528 bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp
-
----
-
D 22 [kswapd0]
-
D 16528 bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp
-
----
-
D 22 [kswapd0]
-
D 16528 bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp
-
----
-
D 22 [kswapd0]
-
D 16528 bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp
-
----
-
D 16528 bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp
-
----
-
Total DISK READ : 0.00 B/s | Total DISK WRITE : 7.87 K/s
-
Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 7.87 K/s
-
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
-
20736 be/ 4 www-data 0.00 B/s 7.87 K/s 0.00 % 0.08 % php-fpm: pool www
找到 PID 号号办事啊
现在已经发现是哪个进程导致的问题，跟着呢，找出磁盘上哪个文件的读写过高问题
使用 lsof 命令 最简单用法是
lsof -p 20736(pid 号)
-
root@iZ28ec5minyZ:~
-
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
-
php-fpm7. 20736 www-data cwd DIR 253, 1 4096 2 /
-
php-fpm7. 20736 www-data rtd DIR 253, 1 4096 2 /
-
php-fpm7. 20736 www-data txt REG 253, 1 4277456 1196882 /usr/sbin/php-fpm7 .0
-
php-fpm7. 20736 www-data mem REG 253, 1 43616 798292 /lib/x86_64-linux-gnu/libnss_files -2.19.so
-
php-fpm7. 20736 www-data mem REG 253, 1 47760 798284 /lib/x86_64-linux-gnu/libnss_nis -2.19.so
-
php-fpm7. 20736 www-data mem REG 253, 1 97296 798280 /lib/x86_64-linux-gnu/libnsl -2.19.so
-
php-fpm7. 20736 www-data mem REG 253, 1 39824 798279 /lib/x86_64-linux-gnu/libnss_compat -2.19.so
-
php-fpm7. 20736 www-data DEL REG 0, 4 21893 /dev/zero
ok！