发布于2026-08-22 阅读(0)
扫一扫,手机访问
最精准的方式是使用sudo iotop -o -P:其中,-o参数能够仅展示真正进行IO操作的进程,从而过滤掉95%的干扰信息;-P参数则只显示进程,不显示线程。DISK READ/WRITE列会呈现自动缩放后的实时带宽(单位为B/s/K/s/M/s),默认每秒刷新一次。若要按照IO等待时间进行排序,快速定位高延迟进程,可通过Shift+P组合键实现。

iotop -o -P 看实时带宽最准不需要猜、不用写脚本,sudo iotop -o -P 是生产环境里最快定位“谁正在吃磁盘”的命令。它默认每秒刷新,DISK READ 和 DISK WRITE 两列就是当前进程的实时读写带宽(单位自动缩放为 B/s、K/s、M/s)。
-o 是关键:只显示此刻真正在读写磁盘的进程,过滤掉内核线程和静默进程(比如 [kthreadd]、[jbd2/sda-8]),否则屏幕 95% 是噪音-P 避免线程干扰:同一进程多个线程会分散在不同行,加 -P 后只显示进程主干,方便快速比对Shift+P 可切换按 IO> 列排序——有些高频小文件操作的进程(如日志轮转)带宽不高,但 I/O 等待占比能到 90%+,靠这个更容易揪出来iotop:没 -o 就等于在一堆 0.00 B/s 行里找数字,根本没法用pidstat -d 1 更适合脚本化监控或看指定进程如果你要写监控脚本、或者只想盯某几个进程(比如 mysqld 或某个 python 服务),pidstat -d 比 iotop 更轻量、输出更结构化。
pidstat -d 1:不带参数只输出一次快照;pidstat -d 0 会卡死终端,千万别试rkB/s 和 wkB/s 这两列:单位是 KB/s,不是累计值,也不是缓存命中量,就是真实块设备读写速率pgrep 配合:pidstat -d 2 -p "$(pgrep -f 'gunicorn.*wsgi')",比手动 ps aux | grep 更可靠(尤其命令含空格或路径不一致时)/proc/[pid]/io 的 read_bytes/write_bytes这两个字段反映的是累计磁盘读写字节数,不是带宽。想算带宽,得自己做差值再除以时间——但容易踩坑。
read_bytes 确实只统计实际从块设备读入的字节(不含 page cache 命中),但它不包含时间戳,两次 cat /proc/1234/io | grep read_bytes 的差值,依赖你采样时机是否稳定iotop 和 pidstat 底层也是轮询这个文件,但它们做了平滑采样(默认 1 秒周期),结果更接近人眼可感知的“实时”read_bytes 不等于物理磁盘实际读取量——比如 RAID 卡或 NVMe 控制器内部重试、对齐写入,内核统计不到iotop 或 pidstat 告诉你“谁在读写”,但不告诉你“为什么慢”或“是不是真有问题”。这时候得交叉验证。
iotop 显示 ja va 进程 DISK WRITE 一直 30M/s,先跑 iostat -x 1 看设备级指标:await > 20ms 或 %util > 80%(SATA/SSD 场景下)说明磁盘已饱和,杀进程没用rsync 或 tar 高 IO 是正常行为,但要用 cat /proc//cmdline | tr ' ' ' ' 确认它真在备份业务数据,而不是误操作扫了整个 /mysqld 持续高写入,可能是 innodb_log_file_size 太小导致 checkpoint 频繁,查 SHOW ENGINE INNODB STATUS 里的 Log sequence number 差值比看 IO 更准ja va 进程 SWAPIN% 也高,说明内存不足在 swap,此时 IO 高是副作用——该看 free -h 和 vmstat 1,而不是继续优化磁盘上一篇:苹果电脑书签栏背景图怎么换
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
正版软件
正版软件
正版软件
正版软件
正版软件
1
2
3
4
5
6
7
8
9