linux io阻塞问题

最新推荐文章于 2025-06-30 09:30:59 发布

原创最新推荐文章于 2025-06-30 09:30:59 发布 · 4.6k 阅读

6 ·

CC 4.0 BY-SA版权

文章标签：

#linux

linux 专栏收录该内容

15 篇文章

订阅专栏

本文介绍了如何在Linux系统中诊断和解决因磁盘读写过高导致的CPU等待问题。通过`top`命令观察CPU等待情况，然后使用`iostat`或`iotop`等工具分析I/O利用率、响应时间和请求次数，确认是否存在I/O阻塞。进一步，通过`ps`和`lsof`命令定位引起问题的进程及其操作的文件，以便进行针对性优化。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

在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%，因为磁盘的并发能力，所以磁盘使用未必就到了瓶颈）。

参考 http://www.cnblogs.com/ggjucheng/archive/2013/01/13/2858810.html

方法二

root@50e261fb9e06:/var# dstat -d
-dsk/total-
 read  writ
1081B  977B
   0     0 
   0     0 
   0     0 
   0     0

使用 dstat ，其实他就是集成了iostat , vmstat,netstat,ifstat 等工具而已

现在确定了是 I／O 问题了，接着找出哪个进程操作哪些文件而导致上面的原因的

同样提供两种方法

第一种根据 linux IO 读写 epoll 机制（省略，研究中...)读写时会合理运用资源，就是某某进程在读资源，就会先sleep 一会，把cpu让给其他进程，那么阻塞的时候就会不间断的sleep 或 ps 里面的状态或“D”状态，所以可以用脚本找出如下可疑进程

 # for x in `seq 1 1 10`; do ps -eo state,pid,cmd | grep "^D"; echo "----"; sleep 5; done
 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
 ----

第二种方法使用 iotop 工具，这个可能需要安装，不是系统自带的

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

找到 PID 号号办事啊

现在已经发现是哪个进程导致的问题，跟着呢，找出磁盘上哪个文件的读写过高问题

使用 lsof 命令最简单用法是

lsof -p 20736(pid 号)

root@iZ28ec5minyZ:~# lsof -p 20736
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

上面的 iostat 可以看到哪个磁盘，lsof 可以找出进程控制的文件，然后找出大致是那几份文件出问题了

ok！

参考资料 http://bencane.com/2012/08/06/troubleshooting-high-io-wait-in-linux/