最直接的办法是用 iotop -o 并按大写 o 排序查 io_rate 最高的进程；再用 lsof -p pid | grep reg 定位具体文件；若 %util > 90% 且 await > 50ms，说明磁盘设备级瓶颈。
用 iotop 实时看哪个进程在狂刷磁盘
最直接的办法就是 iotop —— 它像 top 一样实时刷新，但显示的是每个进程的磁盘读写速率（B/s、KB/s）。需要 root 权限才能看到所有进程的 IO 细节：
- 没装的话先装：
sudo apt install iotop（Debian/Ubuntu）或sudo yum install iotop（RHEL/CentOS） - 运行：
sudo iotop -o，-o表示只显示正在做 IO 的进程，避免干扰 - 按
P按 CPU 排序，按O按 IO 排序（注意是大写 O），这是关键——你要找的就是 IO_RATE 最高的那几行 - 如果看到某进程
IO_RATE长期 >10MB/s，基本就是它在拖慢整个系统响应
查具体文件：用 lsof 结合 iotop 进程 PID
iotop 告诉你“谁在写”，但不告诉你“在写哪个文件”。这时候得靠 lsof 查该进程打开的文件描述符：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 假设
iotop显示 PID 1234 的rsync进程 IO 很高，执行：sudo lsof -p 1234 | grep REG -
REG表示普通文件（regular file），过滤后能快速定位到它正在读写的实际路径，比如/var/log/syslog或/backup/data.tar.gz - 注意：有些进程（如数据库）会通过 mmap 或 buffer 写入，
lsof可能只显示日志文件或 socket，真实热点文件可能藏在临时目录里，比如/tmp/或/var/tmp/
长期趋势分析：用 iostat 看设备级瓶颈
如果问题不是突发而是持续性的，iostat（来自 sysstat 包）更适合看块设备整体负载：
- 安装：
sudo apt install sysstat（确保sysstat服务已启用，否则iostat可能无历史数据） - 执行：
iostat -x 1 5（每秒刷新，共 5 次），重点关注三列：%util（设备忙时百分比）、await（IO 平均等待毫秒）、svctm（服务时间，已废弃，忽略） -
%util > 90%且await持续 >50ms，说明磁盘本身成为瓶颈，不是某个进程的问题，而是硬件或 RAID 配置问题 - 此时再查
iotop就意义不大了——得换 SSD、调队列深度，或者确认是不是 NFS 挂载点卡在远端
别漏掉内核日志里的隐性 IO 源
有些 IO 不走常规文件系统路径，比如内存回收触发的 swap 写入、ext4 journal 刷盘、或 btrfs 的 CoW 导致的重复写。这些不会出现在 lsof 里，但会在 dmesg 或 /proc/diskstats 里留下痕迹：
- 运行：
dmesg | tail -30 | grep -i "write\|io\|kswapd"，留意是否有频繁的kswapd0活动或EXT4-fs warning - 检查：
cat /proc/diskstats | awk '{print $1,$2,$10}' | grep -v "0$"，第 10 列是写入扇区数，持续增长说明底层确实在写，哪怕iotop没抓到对应用户进程 - 特别小心
systemd-journald：默认配置下它会把日志写到/run/log/journal/（内存 tmpfs），但如果磁盘空间不足，会 fallback 到/var/log/journal/，瞬间产生大量小文件写入，iotop看起来像一堆短命线程，实际源头是 journal 自身
ionice，数据库没配 vm.swappiness=1，或者容器里挂载了 host 的 /var/lib/docker 却没限制 blkio weight。这些细节不看上下文，光盯工具输出容易误判。
