确定哪个进程导致磁盘I / O过多?


19

我已经看到了这个问题: 如何识别对磁盘的大量写入?

而且我之前使用过dstatatop ...,但是它们似乎无法查明是什么原因导致了磁盘I / O。例如,从dstat中:

dstat -ta --top-bio
----system---- ----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system-- ----most-expensive----
     time     |usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw |  block i/o process
14-12 16:16:25| 22   3  49  26   0   0|2324k    0 |  17k 6144B|   0     0 |1324     0 |
14-12 16:16:26| 24   3  30  43   0   0|4960k 8192B|1498B 4322B|   0     0 |1494     0 |wget          0  4096B
14-12 16:16:27| 25   4  38  33   0   0|4612k  548k|5011B   27k|   0     0 |1582     0 |kjournald     0    24k
14-12 16:16:28| 23   3  42  32   0   0|5072k    0 |  24k 4368B|   0     0 |1495     0 |

请注意dsk /总有多高-在2到5 MB /秒之间。但是,然后看一看“最昂贵”的列-它只有几个字节,那里只有几个KB,有时甚至什么也没有。'顶'也是一样。显示总体磁盘使用率较高,但单个进程的使用率较低。我正在运行CentOS 5,内核2.6.18-53。

我需要更新的内核版本吗?也许某个地方有一些系统配置设置?“ atop”主页建议安装一些内核修补程序,但是我宁愿不经历配置和编译自己的内核的麻烦。

Answers:


26

iotop(link)for starter;)我还没有看到您发布它的输出。

1:我在使用日志文件系统和atime时经历了几乎相同的情况-但是写入次数更多。

尝试使用noatime重新挂载并关闭文件系统日志记录(仅用于测试),以查看它是否基于文件系统,并且如上所述,如果是基于进程,则查看iotop。

2:我猜这个分区不是刚刚重建的RAID阵列的一部分,对吗?

3:如果您有很多非常小的文件(比实际块设备的块大小和/或文件系统的块大小小得多),并且正在读取这些小文件,则最终会从系统读取整个块,并且大多数这些块中的任何内容都将被读取。

4:如果上面没有帮助,您始终可以通过执行以下操作获取访问的文件列表

echo 1 > /proc/sys/vm/block_dump

请注意,它会大大降低系统性能。在我以前的帖子中可以找到说明


1
用大约5秒钟击败我;)+1
pehrs 2010年

我只是很幸运,但是几乎立即扩展了答案,因为它不完全是问题的答案;)
asdmin 2010年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.