必须加 -o 才能快速定位问题进程，因为默认显示所有进程（含大量无io的内核线程），-o 仅显示当前有实际读写行为的进程，过滤95%以上干扰项，使 java、mysqld 等真实高io进程立即凸显。

直接用 sudo iotop -o 就能看到当前正在读写磁盘的进程及其实时 IO 带宽，这是最常用也最有效的做法。

为什么必须加 -o 才能快速定位问题进程

默认运行 iotop 会列出所有进程（包括内核线程、空闲服务），屏幕被大量 0.00 B/s 行淹没，根本找不到真实 IO 源。-o（或交互中按 o）强制只显示「此刻有实际读写行为」的进程/线程，过滤掉 95% 以上的干扰项。

• 不加 -o：你会看到 [kthreadd]、[migration/0] 这类内核线程长期占屏，但它们根本不产生用户态 IO
• 加 -o 后：java、mysqld、rsync 等真实消耗者立刻浮出水面，DISK READ 和 DISK WRITE 列数值非零
• 注意：-o 是动态开关，进到界面后按 o 键也能即时切换，无需退出重跑

iotop -o 的实时带宽单位和刷新逻辑

默认单位是自动缩放的（B/s、K/s、M/s），但「实时」指的不是瞬时峰值，而是最近一次采样周期（默认 1 秒）内的平均吞吐量。这个值受内核 I/O 统计精度限制，对短时突发 IO（如单次 10ms 写入）不敏感。

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• 想看更平滑的值：用 sudo iotop -o -d 2 把间隔拉到 2 秒，减少毛刺干扰
• 想脚本化解析：必须加 -k（KB/s 固定单位）+ -b（非交互模式），例如 sudo iotop -o -b -n1 -k | tail -n +4 跳过头三行再取数据
• 注意：顶部显示的 Total DISK READ/WRITE 是内核块层统计，可能包含缓存未落盘的数据；而 Actual DISK READ/WRITE 才是真正发往磁盘的量，两者差值大说明写缓存堆积严重

常见误判场景和对应验证动作

看到某个进程 IO 高，别急着 kill，先确认它是否真的在「干坏事」。很多高 IO 是合理行为，比如数据库刷脏页、日志轮转归档。

• 现象：mysqld 持续 DISK WRITE 20M/s，但业务无异常 → 可能是 innodb_log_file_size 小导致频繁 checkpoint，查 SHOW ENGINE INNODB STATUS 中 Log sequence number 和 Last checkpoint 差值
• 现象：rsync 或 tar 进程 IO 高 → 正常，但要检查是否意外在备份整个 / 目录，用 cat /proc/<pid>/cmdline | tr '\0' ' '</pid> 看完整命令行
• 现象：java 进程 SWAPIN >5%，IO% 也高 → 很可能内存不足触发 swap，此时 IO 高是副作用，该看 free -h 和 vmstat 1 的 si/so 列

真正容易被忽略的是：即使 iotop -o 显示某进程 IO 高，它也可能只是「替罪羊」——比如一个 Web 服务把日志全打到磁盘，但瓶颈其实在慢速云盘的随机写能力上。这时候光杀进程没用，得结合 iostat -x 1 看 %util 和 await，才能分清是「进程太贪」还是「磁盘太弱」。