什么进程正在使用我的所有磁盘IO
如果我使用“顶”，我可以看到什么样的CPU忙，什么过程使用我所有的CPU。
如果我使用“iostat -x”，我可以看到什么驱动器正忙。
但是我怎么看到哪个进程正在使用所有驱动器的吞吐量呢？
你正在寻找iotop （假设你有内核> 2.6.20和Python 2.5）。 如果没有，你正在考虑挂钩文件系统。 我build议前者。
要找出处于状态“D”（等待磁盘响应）的进程正在运行：
while true; do date; ps aux | awk '{if($8=="D") print $0;}'; sleep 1; done
要么
watch -n1 -d "ps axu | awk '{if (\$8==\"D\") {print \$0}}'"
Wed Aug 29 13:00:46 CLT 2012 root 321 0.0 0.0 0 0 ? D May28 4:25 \_ [jbd2/dm-0-8] Wed Aug 29 13:00:47 CLT 2012 Wed Aug 29 13:00:48 CLT 2012 Wed Aug 29 13:00:49 CLT 2012 Wed Aug 29 13:00:50 CLT 2012 root 321 0.0 0.0 0 0 ? D May28 4:25 \_ [jbd2/dm-0-8] Wed Aug 29 13:00:51 CLT 2012 Wed Aug 29 13:00:52 CLT 2012 Wed Aug 29 13:00:53 CLT 2012 Wed Aug 29 13:00:55 CLT 2012 Wed Aug 29 13:00:56 CLT 2012 root 321 0.0 0.0 0 0 ? D May28 4:25 \_ [jbd2/dm-0-8] Wed Aug 29 13:00:57 CLT 2012 root 302 0.0 0.0 0 0 ? D May28 3:07 \_ [kdmflush] root 321 0.0 0.0 0 0 ? D May28 4:25 \_ [jbd2/dm-0-8] Wed Aug 29 13:00:58 CLT 2012 root 302 0.0 0.0 0 0 ? D May28 3:07 \_ [kdmflush] root 321 0.0 0.0 0 0 ? D May28 4:25 \_ [jbd2/dm-0-8] Wed Aug 29 13:00:59 CLT 2012 root 302 0.0 0.0 0 0 ? D May28 3:07 \_ [kdmflush] root 321 0.0 0.0 0 0 ? D May28 4:25 \_ [jbd2/dm-0-8] Wed Aug 29 13:01:00 CLT 2012 root 302 0.0 0.0 0 0 ? D May28 3:07 \_ [kdmflush] root 321 0.0 0.0 0 0 ? D May28 4:25 \_ [jbd2/dm-0-8] Wed Aug 29 13:01:01 CLT 2012 root 302 0.0 0.0 0 0 ? D May28 3:07 \_ [kdmflush] root 321 0.0 0.0 0 0 ? D May28 4:25 \_ [jbd2/dm-0-8] Wed Aug 29 13:01:02 CLT 2012 Wed Aug 29 13:01:03 CLT 2012 root 321 0.0 0.0 0 0 ? D May28 4:25 \_ [jbd2/dm-0-8]
从结果中可以看出，jdb2 / dm-0-8（ext4日志进程）和kdmflush不断阻塞你的Linux。
有关更多详细信息，此URL可能会有所帮助： Linux等待IO问题
atop也可以很好地运行，即使在不能运行iotop的较老的CentOS 5.x系统上也可以轻松安装。 打d显示磁盘细节， ? 求助。
ATOP - mybox 2014/09/08 15:26:00 ------ 10s elapsed PRC | sys 0.33s | user 1.08s | | #proc 161 | #zombie 0 | clones 31 | | #exit 16 | CPU | sys 4% | user 11% | irq 0% | idle 306% | wait 79% | | steal 1% | guest 0% | cpu | sys 2% | user 8% | irq 0% | idle 11% | cpu000 w 78% | | steal 0% | guest 0% | cpu | sys 1% | user 1% | irq 0% | idle 98% | cpu001 w 0% | | steal 0% | guest 0% | cpu | sys 1% | user 1% | irq 0% | idle 99% | cpu003 w 0% | | steal 0% | guest 0% | cpu | sys 0% | user 1% | irq 0% | idle 99% | cpu002 w 0% | | steal 0% | guest 0% | CPL | avg1 2.09 | avg5 2.09 | avg15 2.09 | | csw 54184 | intr 33581 | | numcpu 4 | MEM | tot 8.0G | free 81.9M | cache 2.9G | dirty 0.8M | buff 174.7M | slab 305.0M | | | SWP | tot 2.0G | free 2.0G | | | | | vmcom 8.4G | vmlim 6.0G | LVM | Group00-root | busy 85% | read 0 | write 30658 | KiB/w 4 | MBr/s 0.00 | MBw/s 11.98 | avio 0.28 ms | DSK | xvdb | busy 85% | read 0 | write 23706 | KiB/w 5 | MBr/s 0.00 | MBw/s 11.97 | avio 0.36 ms | NET | transport | tcpi 2705 | tcpo 2008 | udpi 36 | udpo 43 | tcpao 14 | tcppo 45 | tcprs 1 | NET | network | ipi 2788 | ipo 2072 | ipfrw 0 | deliv 2768 | | icmpi 7 | icmpo 20 | NET | eth0 ---- | pcki 2344 | pcko 1623 | si 1455 Kbps | so 781 Kbps | erri 0 | erro 0 | drpo 0 | NET | lo ---- | pcki 423 | pcko 423 | si 88 Kbps | so 88 Kbps | erri 0 | erro 0 | drpo 0 | NET | eth1 ---- | pcki 22 | pcko 26 | si 3 Kbps | so 5 Kbps | erri 0 | erro 0 | drpo 0 | PID RDDSK WRDSK WCANCL DSK CMD 1/1 9862 0K 53124K 0K 98% java 358 0K 636K 0K 1% jbd2/dm-0-8 13893 0K 192K 72K 0% java 1699 0K 60K 0K 0% syslogd 4668 0K 24K 0K 0% zabbix_agentd
这清楚地显示了java pid 9862是罪魁祸首。
TL; DR
如果你可以使用iotop ，那就这样做。 否则这可能有帮助。
使用top ，然后使用这些快捷键：
d 1 = set refresh time from 3 to 1 second 1 = show stats for each cpu, not cumulated
这必须显示至less一个核心的值> 1.0 wa – 如果没有diskwaits，那么根本没有IO负载，也不需要进一步观察。 重要负荷通常开始> 15.0 wa 。
x = highlight current sort column < and > = change sort column R = reverse sort order
select“S”，进程状态栏。 颠倒sorting顺序，使'R'（运行）进程显示在最上面。 如果你能发现'D'进程（等待磁盘），你有一个指标可能是你的罪魁祸首。
对于KDE用户，您可以使用“ctrl-esc”顶部调用系统灵活性监视器，并且存在具有进程ID和名称的I / O活动图表。
由于“新用户状态”，我无权上传图片，但是您可以查看下面的图片。 它有一个IO读写的列。
你有没有考虑lsof （列出打开的文件）？
