linux io阻塞问题

本文介绍了如何在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/





### Linux I/O 阻塞原因 在Linux环境中,I/O操作可能会因为多种情况而进入阻塞状态。当进程尝试执行读写操作时,如果目标资源不可用,则该进程会被挂起直到条件满足。 对于管道(Pipe)和先进先出队列(FIFO),特定情况下会触发信号并导致阻塞行为[^2]: - 当向已满的管道或FIFO写入数据时,如果没有足够的空间容纳新数据,那么写操作将会被阻塞等待可用的空间; - 如果从空闲的管道或FIFO中读取数据,在有新的输入到来之前也会发生阻塞现象; 另外一种常见的原因是文件系统的分配方式影响到磁盘访问效率。变长不连续存储阻止会产生浪费的空间,并且限制记录大小不超过块尺寸,这可能导致不必要的延迟以及性能下降问题[^1]。 ### 解决方案 为了缓解这些问题带来的负面影响,可以采取如下措施来优化系统表现: #### 使用非阻塞模式 通过设置O_NONBLOCK标志位可以让打开文件描述符变为非阻塞形式,这样即使遇到上述提到的情况也不会使程序陷入长时间等待状态而是立即返回错误码EAGAIN/EWOULDBLOCK给调用者处理。 ```c int flags = fcntl(fd, F_GETFL); fcntl(fd, F_SETFL, flags | O_NONBLOCK); ``` #### 调整缓冲区策略 适当调整应用程序内部缓存机制有助于减少频繁的小规模传输次数从而提高整体吞吐量。例如增大发送/接收窗口尺寸或者启用零拷贝技术等手段都可以有效改善网络通信中的瓶颈状况。 #### 文件系统层面改进 针对因文件系统设计缺陷所引发的数据布局碎片化严重等问题,可以通过定期整理卷内对象分布结构(如defrag)、选用更高效的日志型文件系统(XFS、ext4)等方式来进行预防性维护工作[^3]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值