确定哪个进程导致磁盘 I/O 负担过重?

确定哪个进程导致磁盘 I/O 负担过重?

我见过这个问题: 如何识别磁盘重度写入?

我已经用过统计信息在顶上之前...但它们似乎无法确定哪个进程导致了磁盘 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/total 有多高——介于 2 到 5 MB/秒之间。但是,看看“最昂贵”列——这里只有几个字节,那里只有几 KB,有时甚至没有。这与“atop”的情况相同。显示总体磁盘使用率高,但单个进程的使用率低。我正在运行 CentOS 5,内核为 2.6.18-53。

我是否需要更新的内核版本?也许需要某些系统配置设置?“atop”主页建议安装一些内核补丁,但我不想经历配置和编译自己的内核的麻烦。

答案1

iotop (关联) 首先;)我还没有看到你发布它的输出。

1:我在日志文件系统和atime方面遇到过几乎相同的情况 - 但是写入次数更多。

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

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

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

4:如果以上方法都不起作用,你始终可以通过执行以下代码来获取访问的文件列表

echo 1 > /proc/sys/vm/block_dump

请注意,这会大大降低系统性能。说明可在我的上一篇帖子在这里

相关内容