iostat通过%util列判断磁盘是否跑满，该值达100%表示设备饱和；常用命令iostat -xk 1，重点关注rkb/s、wkb/s和await；iotop需root权限，可按o/p/a键筛选进程、切换视图或查看累计io，二者统计口径不同导致输出差异。
怎么用 iostat 看磁盘是否被跑满
直接看 %util 列——它代表设备忙于处理 I/O 请求的时间百分比，不是“使用率”字面意义的容量占用，而是饱和度指标。持续接近或等于 100% 就说明该设备已无余力响应新请求。
常用命令：iostat -xk 1（每秒刷新一次扩展统计，单位为 KB）；重点关注以下几列：
-
rKB/s和wKB/s：读/写吞吐量，数值异常高可能对应大文件拷贝、数据库 dump 或日志刷盘 -
await：I/O 请求平均等待时间（毫秒），长期 > 50ms 常意味着队列堆积或磁盘响应慢 -
svctm已废弃，内核 2.6.33+ 后不再可靠，别再依赖它 - 若只关心某块盘（如
sda），加-p sda；想看所有分区，用-p ALL
怎么用 iotop 找出吃 IO 的罪魁进程
iotop 是唯一能实时按进程/线程维度下钻的工具，但必须用 root 权限运行，否则看不到完整数据。
启动后默认按当前 I/O 带宽降序排列，实用操作如下：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 按
o键只显示有实际 I/O 活动的条目（过滤掉空闲进程） - 按
p键切换显示模式：从线程（TID）切回进程（PID），避免被同一进程的多个线程刷屏 - 按
a键切换为累计 I/O 量视图，适合排查长时间运行的写入任务（比如备份脚本） - 非交互式导出：用
sudo iotop -b -n 5 -d 2表示每 2 秒采样一次，共 5 次，适合写进监控脚本
iostat 和 iotop 输出不一致？常见原因
两者统计口径不同，不是 bug，是设计使然：
-
iostat统计的是块设备层（如/dev/sda）的真实硬件请求，含内核缓存、合并、重试等开销 -
iotop统计的是进程发起的 I/O 系统调用，受 page cache 影响极大——如果数据全在缓存里读，iotop显示很高，iostat却几乎为 0 - 当
iostat显示高%util但iotop没有明显大户时，大概率是内核线程（如kswapd、ksmd）或 direct I/O 场景（如数据库裸设备访问）导致 - 某些容器环境（尤其是 runC 底层）中，
iotop可能无法正确映射 cgroup I/O，此时需结合cat /sys/fs/cgroup/io.stat查看
查完 IO 高之后，下一步该做什么
定位到进程只是起点，真正耗时的往往在路径上：
- 先确认挂载点空间是否告急：
df -h查看/var/log、/tmp或业务目录是否 >90%，空间不足会触发频繁元数据更新和 block 回收 - 对高 IO 进程的 PID，用
lsof -p PID看它在写哪些文件；特别注意.log、.tmp、.journal类型 - 如果是数据库类应用，检查其日志策略（如 MySQL 的
innodb_flush_log_at_trx_commit=1）和 buffer pool 大小，这类配置直接影响随机写放大 - 云环境要区分：是实例本地盘性能不足，还是云盘 IOPS 配额被占满（如阿里云系统盘默认只有 180 IOPS）
真实场景里，%util 高但 iotop 空白，或者 iotop 显示某个进程猛写，但 lsof 看不到具体文件——这种矛盾点最值得深挖，往往指向内核模块、容器运行时或异步写机制。
