iostat -d -p ALL 1可同时监控物理磁盘及所有分区的IO负载，重点观察后续刷新行的%util、await和吞吐量，结合-N选项解析LVM名称，并优先对比nvme0n1等物理设备整体利用率再下钻分区。
直接用 iostat -d -p ALL 1 就能看清物理磁盘和所有分区的读写负载分布，不需要 -P 参数——iostat 命令本身没有 -P 选项，这可能是混淆了其他工具（如 pidstat）或误记。
要判断哪个分区在扛热点 IO，关键不是“加什么参数”，而是选对命令组合 + 看懂指标含义 + 对比层级关系。
✅ 正确命令：同时看物理盘 + 所有分区
iostat -d -p ALL 1
-
-d：只显示设备（不显示 CPU） -
-p ALL：显示所有块设备 及其所有分区（如sda、sda1、sda2；nvme0n1、nvme0n1p1） -
1：每秒刷新一次，便于观察动态变化
? 提示：至少观察 5–10 秒，避免被瞬时抖动误导；别只看第一行（那是系统启动以来的平均值），重点看后续实时刷新的数据。
? 怎么判断“热点 IO”落在哪个分区？
不是比谁的 kB_read/s 数字大，而是看三组关系：
物理盘 vs 分区总和
比如sda的kB_wrtn/s = 120MB/s，但sda1 + sda2 + sda3加起来只有 40MB/s → 说明有直写裸设备、LVM 映射、或加密层（如 dm-crypt）在绕过分区统计，真实压力不在分区层。分区之间不均衡
sda1的%util = 92%，sda2只有3%→ 热点明显集中在sda1，比如数据库数据目录挂载在此。-
高吞吐 ≠ 高压力，低吞吐 ≠ 无问题
sda1的kB_read/s只有 2MB/s，但await = 180ms、%util = 75%→ 典型小文件随机读，IO 效率差，应用可能卡顿。这才是隐性热点。
? LVM 或加密卷场景：让名字可读
如果看到一堆 dm-0、dm-1，很难对应业务：
iostat -x -N 1
-
-N：显示 device mapper 的逻辑名（如centos-root、ubuntu--vg-swap_1），而不是dm-0 -
-x：启用扩展指标，必加（否则看不到await、avgqu-sz等关键项）
这样你一眼就能看出是 docker--vg-docker--pool 还是 k8s--vg-var-lib-kubelet 在吃 IO。
⚠️ NVMe 用户注意命名陷阱
-
nvme0n1是整块 NVMe 盘（物理设备） -
nvme0n1p1是它的第一个分区
❌ 错误做法：盯着nvme0n1p1的%util优化，却忽略nvme0n1本身已 99% → 实际瓶颈在盘整体，不是分区
建议始终先看 nvme0n1，再下钻到具体 p* 分区做归属分析。
? 小结：三步定位热点 IO 分区
- 运行
iostat -d -p ALL 1，盯住r/s、w/s、kB_read/s、kB_wrtn/s、await、%util - 对比物理设备与各分区数值总和，确认 IO 是否“漏统计”
- 结合
-N（LVM 场景）或lsblk（查挂载点），把高%util/ 高await的设备映射到实际业务路径（如/var/lib/mysql）
不复杂但容易忽略。
