因此，我注意到 iotop 不适用于 2.6.18，因为它低于 2.6.20 并且需要 Python 2.6+。我做了一些研究，发现了这篇文章： http://lserinol.blogspot.com/2009/09/io-usage-per-process-on-linux.html
根据此，如果这些进程在 /proc/pid#/io（其中 pid# 是进程 #）中有 io 统计信息，那么无论内核版本如何，都可以执行此操作。因此，实际上，我可以将 Python 升级到 2.6 并测试 iotop。但是，我的 Linux 版本 CentOS 版本 5.5（最终版）目前仅支持 Python 2.4.3-44.el5。如果我要从 yum 卸载，结果就不太好看。它最终要卸载 235 个软件包，其中大多数都非常重要！
我在网上看到过一个地方（我忘记了昨天的 URL），你可以同时安装 Python 2.6+，然后让 iotop 使用的 rpm 安装。好吧，我没有选择那条路线。
我想，管他呢，让我们在 bash 中编写 iotop（不是复制它，而是对其进行逆向工程，而不实际查看它的代码/正在使用的内容）。我以为它只会抓取 /proc/pid#/io 文件并解析统计数据。
因此，我编写了一个脚本，通过从所有 /proc/pid#/io 文件中收集所有这些统计信息来获取前 10 个 rchar、wchar、read_bytes 和 write_bytes，按每个指标对它们进行排序，然后获取前 10 个最高值。
结论是，这些数据看起来完全没用。
是否有人知道任何高级 Linux 资源，我可以在其中弄清楚如何获取这些 /proc/pid#/ 目录并弄清楚它们到底在对磁盘上的 io 做什么？
我的主要目标是找出导致磁盘负载过高的原因。我只知道它位于 / 分区（在本例中为 /dev/sda2）上，而且我不确定如何在没有 iotop 帮助的情况下缩小范围。如果我运行 iostat 来获取每秒 1 分钟的指标，它给出的第一个结果显示“kB_read/s”很高，所以这让我认为它主要是在读取。但是，如果我查看它每秒提供的更新，它实际上只是显示 kB_wrtn/s 的值。这让我认为 iostat 给我的初始值具有误导性。
答案1
也许blktrace有适用于 CentOS 5.5 的软件包？该btrace命令为您提供了 I/O 子系统的非常详细的视图。