iotop可直接定位高I/O进程，无需ps配合；它已显示PID、USER、COMMAND等完整信息，真正需关注的是IO>与DISK READ/WRITE列，并确保root权限、内核taskstats启用及使用-o-P参数。
直接用 iotop 就能定位高 I/O 进程，ps 在这里不是必需环节。真正需要的是理解 iotop 的输出逻辑、确认权限与内核支持、再结合少量辅助命令做交叉验证——而不是机械地“iotop + ps”串联操作。
为什么通常不需要 ps 配合 iotop
iotop 本身已显示完整进程信息：PID、USER、PRIO、IO>、DISK READ/WRITE、COMMAND。它不像 top 那样只显示 CPU 时间，而是专为磁盘 I/O 设计，所有列都围绕读写行为展开。你看到的 COMMAND 列就是进程启动时的完整命令行（含参数），足够识别服务类型或脚本路径。
ps 的常见用途（如查状态、启动时间、父进程）在 I/O 排查中极少用到。强行加 ps，反而容易分散注意力，甚至因时间差导致 PID 对不上。
真正有用的组合方式：iotop + 其他针对性命令
当 iotop 找出可疑 PID 后，可按需选用以下命令深入确认，比 ps 更有效：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
查看该进程打开的文件和设备：
sudo lsof -p PID—— 确认它在读写哪些具体文件、日志、数据库文件或块设备 -
查看 I/O 统计详情：
cat /proc/PID/io—— 获取累计读写字节数、系统调用次数等原始数据，验证 iotop 实时速率是否持续异常 -
检查进程所属服务或容器：
systemctl status $(ps -o comm= -p PID)或sudo crictl ps | grep $(ps -o pid= -p PID)（K8s 环境）—— 定位上层业务归属 -
观察线程级 I/O（必要时）：去掉 iotop 的
-P参数，或用sudo iotop -p PID单独跟踪——某些 Java/Python 应用的 I/O 可能集中在某个工作线程
iotop 必须跑对的三个前提
很多用户以为“没看到数据”是命令问题，其实是环境没准备好：
-
必须用 root 权限：普通用户即使 sudo，也需确保具备
CAP_SYS_ADMIN能力；最小化安装的系统常缺此配置 -
内核需启用 taskstats：运行
zcat /proc/config.gz 2>/dev/null | grep -i taskstats，若无输出，说明内核不支持，iotop 无法工作 -
用对参数才看得见真实活动：
sudo iotop -o -P是最稳组合——-o过滤静默进程，-P屏蔽内核线程干扰，避免被kthreadd、kauditd等占满屏幕
看懂 iotop 输出的关键列
界面里真正要盯住的只有两列：
- IO>：I/O 等待时间占比。值越接近 100%，说明进程越频繁卡在磁盘响应上（比如小文件高频刷盘、慢存储随机读）。哪怕 DISK WRITE 只有 200KB/s，IO> 达 95% 也极可疑
- DISK READ / DISK WRITE：实时吞吐量。关注带宽峰值是否超出磁盘合理能力（如 SATA SSD 持续写入超 400MB/s 就值得查）
按 Shift+P 切换为按 IO> 排序，比默认按 WRITE 排序更能揪出“低带宽但高延迟”的隐形杀手。
