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 排序更能揪出“低带宽但高延迟”的隐形杀手。