什么进程正在使用我所有的磁盘 IO [关闭]
Posted
技术标签:
【中文标题】什么进程正在使用我所有的磁盘 IO [关闭]【英文标题】：What Process is using all of my disk IO [closed] 【发布时间】：2010-10-04 01:57:00 【问题描述】：如果我使用“top”，我可以看到哪个 CPU 很忙，以及哪个进程正在使用我所有的 CPU。
如果我使用“iostat -x”，我可以看到哪个驱动器正忙。
但是我如何查看哪个进程正在使用驱动器的所有吞吐量？
【问题讨论】：
嗯，从技术上讲，Linux 也是如此，因为用户进程只修改页面缓存中的页面...... ;) 只是我的问题和我正在寻找的答案，但这种问题不是更适合 SuperUser 吗？ 这就是 Linux 不如 Solaris 和 MacOS 的原因，因为它们内置了 dtrace，这使得查找起来非常简单：-/ 【参考方案1】：对于 KDE 用户，您可以使用 'ctrl-esc' 顶部调用系统活动监视器，并且有带有进程 ID 和名称的 I/O 活动图表。
由于“新用户状态”，我没有上传图片的权限，但您可以查看下面的图片。它有一个用于IO读写的列。
（来源：kde.org）
【讨论】：
【参考方案2】：带有 -a 标志的 iotop：
-a, --accumulated show accumulated I/O instead of bandwidth
【讨论】：
【参考方案3】：要找出处于“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 Wait-IO Problem
【讨论】：
【参考方案4】：TL;DR
如果您可以使用iotop，请这样做。否则这可能会有所帮助。
使用top，然后使用这些快捷方式：
d 1 = set refresh time from 3 to 1 second
1 = show stats for each cpu, not cumulated
这必须显示至少一个内核的值> 1.0 wa - 如果没有磁盘等待，则根本没有 IO 负载，无需进一步查看。大量负载通常从 > 15.0 wa 开始。
x = highlight current sort column
< and > = change sort column
R = reverse sort order
选择“S”，即进程状态列。颠倒排序顺序，使“R”（运行）进程显示在顶部。如果你能发现“D”进程（等待磁盘），你就知道你的罪魁祸首可能是什么。
【讨论】：
【参考方案5】：你考虑过lsof（列出打开的文件）吗？
【讨论】：
只显示打开的文件句柄，而不是每个文件的 MB/s。 iotop 就是这样做的。【参考方案6】：您正在寻找 iotop（假设您的内核 >2.6.20 和 Python 2.5）。如果做不到这一点，您正在考虑挂钩文件系统。我推荐前者。
【讨论】：
iotop 似乎显示的是 I/O 带宽，而不是进程消耗的 IOPS 数。这不是超级相关的。与高速写入大量连续数据的进程相比，执行大量小写入+同步的进程将消耗更多的磁盘 IO 容量。
对于小型写入，我看到的只是 iotop 中的 [jdb2/nvme0n1p1]，但我很幸运能够启用 /proc/sys/vm/block_dump 并将输出与健康/稳定的系统进行比较 lxadm.com/Simple_filesystem_read/write_tracing_with_/proc/sys/… 它有帮助找到一个不断产生 kubectl 请求的 docker 容器，用 /home/spinnaker/.kube/cache/discovery/.../serverresources.json 中的条目耗尽 EBS 卷的突发信用。一旦您将范围缩小到用户/进程名称，iotop -atku systemd-network | grep kubectl 之类的名称也可能会有所帮助【参考方案7】：
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 是罪魁祸首。
【讨论】：
以上是关于什么进程正在使用我所有的磁盘 IO [关闭]的主要内容，如果未能解决你的问题，请参考以下文章