如何通过Iostat-P命令在Linux中分析物理磁盘分区读写负载，以识别热点IO区域？

本文共计859个文字，预计阅读时间需要4分钟。

使用命令 `iostat -d -p ALL 1` 可以查看物理磁盘和所有分区的读写负载分布，无需使用 `-P` 参数。

要判断哪个分区在扛热点 IO，关键不是“加什么参数”，而是选对命令组合 + 看懂指标含义 + 对比层级关系。

---

✅ 正确命令：同时看物理盘 + 所有分区

iostat -d -p ALL 1

• -d：只显示设备（不显示 CPU）
• -p ALL：显示所有块设备 及其所有分区（如 sda、sda1、sda2；nvme0n1、nvme0n1p1）
• 1：每秒刷新一次，便于观察动态变化

---

? 怎么判断“热点 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）

不复杂但容易忽略。