iostat —— 磁盘 IO 压力表
iostat —— 磁盘 IO 压力表
分类：01 系统监控与性能 适用：Linux（sysstat 包）。CentOS 7 为 10.1.x，新发行版为 12.x 一句话：判断磁盘是不是瓶颈、瓶颈在延迟还是吞吐，第一个看它。
1. 它解决什么问题
- 磁盘到底忙不忙？
%util是否打满？ - 是读多还是写多？IOPS 多少？单次 IO 平均等多久（
await）？ - 云盘/机械盘/SSD 的实际性能是否符合预期。
2. 安装与前提
# 安装
apt install -y sysstat
dnf install -y sysstat
# 采集服务（sar 需要，iostat 实时不需要）
systemctl enable --now sysstat
3. 核心用法
iostat # 一次快照（第一行是开机以来平均）
iostat 1 5 # 每秒 1 次，共 5 次
iostat -x 1 # 扩展统计（最重要，持续输出）
iostat -x -m 1 # 单位 MB/s
iostat -x -z 1 # 只显示有活动的设备
iostat -d -p sda 1 # 只看 sda 及其分区
iostat -t 1 # 带时间戳
iostat -c 1 # 只看 CPU
iostat -N 1 # 显示 LVM 逻辑卷名
iostat -o JSON -x 1 # JSON 输出（sysstat 11.6+）
4. -x 输出怎么读
Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s wrqm/s %wrqm w_await wareq-sz aqu-sz %util
sda 12.00 480.00 0.00 0.00 1.20 40.00 85.00 1360.00 3.00 3.40 2.80 16.00 0.35 8.20
nvme0n1 520.00 13312.00 0.00 0.00 0.18 25.60 3100.00 63488.00 0.00 0.00 0.22 20.48 0.72 62.10
| 字段 | 含义 | 判读 |
|---|---|---|
r/s w/s |
每秒读/写次数（IOPS） | 机械盘 ~100-200，SATA SSD 数万，NVMe 数十万 |
rkB/s wkB/s |
每秒读/写吞吐 | 与带宽上限比 |
rrqm/s wrqm/s |
每秒合并的请求数 | 合并多说明顺序 IO 多 |
%rrqm %wrqm |
合并比例 | 高说明内核在帮合并 |
r_await w_await |
平均等待时间（ms，含排队） | 最关键：机械盘 <10ms 正常，SSD <1ms，NVMe <0.5ms |
rareq-sz wareq-sz |
平均请求大小（KB） | 小且随机 → IOPS 瓶颈；大 → 带宽瓶颈 |
aqu-sz |
平均队列长度（老版本叫 avgqu-sz） |
持续 >1 说明有排队 |
%util |
设备繁忙百分比 | 接近 100% 说明设备饱和 |
svctm |
平均服务时间 | 已废弃，不可信，忽略 |
关键判读组合
| 现象 | 结论 |
|---|---|
%util 接近 100%，await 高 |
设备饱和，真瓶颈 |
%util 低，await 高 |
排队不在设备层：网络存储延迟、多路径、虚拟化层 |
%util 高，await 低 |
小 IO 密集，设备被请求打满但每次很快（NVMe 常见） |
w/s 高、wareq-sz 小 |
随机写，看 IOPS 上限 |
wkB/s 高、w/s 低 |
顺序写，看带宽上限 |
aqu-sz 持续增长 |
请求堆积，后端扛不住 |
%util对 NVMe/RAID 会失真：这类设备支持高并发，即使%util100% 也可能还有余量。此时更应看await和队列深度。
5. 实战场景
5.1 判断磁盘是否是瓶颈
vmstat 1 5 # 先看 wa 和 b
iostat -x 1 5 # 再看具体设备
wa 高 + 某设备 %util 90%+ + await 明显高于平时 → 确认磁盘瓶颈。再 pidstat -d 1 找进程。
5.2 验证云盘性能是否达标
# 先看规格标称（示例：ESSD PL1 约 5万 IOPS / 350MB/s）
iostat -x 1 10
fio --name=t --filename=/data/test.bin --size=4G --rw=randwrite --bs=4k \
--iodepth=32 --numjobs=4 --direct=1 --runtime=60 --group_reporting
用
fio压出来的才叫能力上限，iostat只是观察现状。
5.3 找出谁在写盘
iostat -x 1 3 # 确认 sdb 写高
pidstat -d 1 5 # 按进程看 kB_wr/s
iotop -oP # 交互式看，按累计排序
5.4 定位 IO 大小与模式
iostat -x 1
# wareq-sz 平均 4KB 且 w/s 很高 → 随机小写（数据库 redo、日志 fsync）
# wareq-sz 平均 512KB+ → 顺序大写（备份、导入）
小随机写优化方向：换 SSD、加大 innodb_log_file_size、vm.dirty_ratio 调优、应用层合并写。
大顺序写优化方向：限速（ionice、cgroup io.max）、错峰、换更高带宽盘。
5.5 LVM / 多路径下看真实设备
iostat -x -N 1 # 显示 dm-* 对应的 LV 名
iostat -x 1 # dm-0 是逻辑卷，sdb 是物理盘，两者都要看
multipath -ll # 多路径环境确认聚合情况
6. 常见坑
- 第一次输出是开机以来平均：必须看后续采样行。
%util不等于饱和度：SSD/RAID/NVMe 上可超过 100%（老内核）或长期 100% 但仍有性能余量。svctm已废弃：sysstat 作者明确说明不可用，别拿它算延迟。await含排队时间：它变大可能是队列长，不一定是磁盘本身慢，结合aqu-sz看。- 云盘有突发额度：小规格云盘初始有 burst，压测前几分钟数据漂亮，之后掉到基线。
iostat看不到 tmpfs / 内存盘：这些不经过块设备层。- 容器内
iostat显示宿主机设备：容器里没有隔离，要按 cgroupio.stat看。 - 老版本无
-o JSON：CentOS 7 的 sysstat 10.1 不支持，脚本解析用 awk 取列。 %util由(r/s + w/s) * svctm估算（旧内核），本质不可靠，新内核改用实际忙时统计。
7. 速查表
iostat -x 1 5 # 最常用
iostat -x -m 1 # MB 单位
iostat -x -z 1 # 隐藏空闲设备
iostat -d -p sda 1 # 单盘分区
iostat -c 1 # CPU
iostat -N -x 1 # LVM 名
# 判读：%util 高 + await 高 = 真饱和；%util 低 + await 高 = 上层延迟
# wareq-sz 小 = IOPS 瓶颈；wareq-sz 大 = 带宽瓶颈
# 找进程：pidstat -d 1 / iotop -oP