必须加 -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' ' '看完整命令行 - 现象：
java进程SWAPIN>5%，IO%也高 → 很可能内存不足触发 swap，此时 IO 高是副作用，该看free -h和vmstat 1的si/so列
真正容易被忽略的是：即使 iotop -o 显示某进程 IO 高，它也可能只是「替罪羊」——比如一个 Web 服务把日志全打到磁盘，但瓶颈其实在慢速云盘的随机写能力上。这时候光杀进程没用，得结合 iostat -x 1 看 %util 和 await，才能分清是「进程太贪」还是「磁盘太弱」。
