直接用 iotop -o 看实时高 io 进程是最快最准的起点，它只显示正在做磁盘 i/o 的进程，默认按 io> 列降序排列，一眼锁定瓶颈源；必须用 sudo iotop -o 才能查看系统级进程，否则易漏掉 mysqld、dockerd 等关键服务。
直接用 iotop -o 看实时高 IO 进程
绝大多数场景下，iotop -o 是最快、最准的起点。它只显示正在做磁盘 I/O 的进程（过滤掉空闲进程），默认按 IO> 列降序排列，一眼就能锁定瓶颈源。
常见错误：普通用户运行 iotop 只能看到自己的进程；不加 -o 时界面被大量休眠进程淹没，关键信息被冲散。
- 必须用
sudo iotop -o，否则看不到系统级进程（如mysqld、dockerd、内核线程） - 按
左右箭头键可切换排序列——想查写入大户就按右箭头切到DISK WRITE列 - 按
a键可展开COMMAND显示完整路径，避免同名进程混淆（比如多个python） - 如果发现某进程
IO>长期 >95% 且DISK WRITE持续在几 MB/s 以上，基本就是它了
确认磁盘设备是否真饱和，再查进程
先跑 iostat -x 1，看 %util 和 await。如果所有设备 %util 都低于 60%，那所谓“IO 高”可能是误报或由其他资源（如内存换页）引起，iotop 结果参考价值下降。
典型误判场景：内存严重不足时，swappiness 触发频繁 swap 写入，iotop 会显示 kswapd0 或 ksmd 占高 IO，但根源是内存不够，不是磁盘慢。
-
%util ≥ 90%且await > 50ms才算真正磁盘瓶颈 - 若
nvme0n1饱和但sda很闲，说明问题集中在 NVMe 盘挂载的路径（如/var/lib/docker），后续查进程可优先关注该路径下的服务 -
iostat -x 1输出中wkB/s和rkB/s值远高于平时基线，才值得继续深挖进程
用 pidstat -d 1 做脚本化或离线分析
iotop 是交互式工具，不方便集成进监控脚本或回溯历史。这时 pidstat -d 1 更合适——它每秒输出一次各进程的读写速率（单位 KB/s），输出格式稳定，易用 awk 或 sort 处理。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
注意：pidstat 来自 sysstat 包，不是所有最小化系统默认安装；它不显示 IO> 百分比，无法反映进程是否被 IO 卡住，只反映吞吐量。
- 查当前写入最高的 5 个进程：
pidstat -d 1 1 | awk '$8 ~ /[0-9]/ {print $8,$10,$12}' | sort -k1 -nr | head -5 -
$8是kB_wr/s，$10是kB_rd/s，$12是进程名；字段位置可能因版本微调，建议先跑一次看表头 - 长期监控可配合
tee记录日志：pidstat -d 5 | tee /tmp/pidstat-io.log - 它不显示线程，默认聚合到进程级别，比
iotop -P更干净
别忽略 /proc/<pid>/io</pid> 里的累计值
有些进程是短时爆发型写入（比如日志轮转、备份脚本），iotop 实时速率可能一闪而过，pidstat 采样间隔也容易错过。这时直接读 /proc/<pid>/io</pid> 的累计字节数更可靠。
重点看 write_bytes 和 read_bytes，它们是自进程启动以来的总字节数，不受采样窗口影响。结合 ps -o pid,comm,etime 看进程存活时间，能算出平均写入速率。
- 快速找写得最多的进程：
find /proc/[0-9]* -name io -exec awk '/write_bytes/ {print $NF,FILENAME}' {} \; 2>/dev/null | sort -nr | head -5 -
write_bytes值极大但DISK WRITE实时为 0？说明进程已结束写入，但缓冲区尚未刷盘（如fsync未调用） - 注意：
rchar/wchar统计的是系统调用字节数，含缓存读写；read_bytes/write_bytes才是真正落盘的数据量
实际排查时，iotop -o 启动最快，但它的实时性是一把双刃剑——容易受瞬时抖动干扰。真正稳住结论，得交叉验证：iostat 确认设备层瓶颈 → iotop 锁定候选进程 → /proc/*/io 查累计值排除误报 → 必要时用 strace 跟踪 open/write/fdatasync 系统调用。磁盘 IO 问题的根因常藏在“谁在写什么文件”这一步，而不是“谁写得多”。
