10.3 云盘性能模型 (IOPS / 吞吐 / 延迟)
一句话
云盘性能由三个数共同决定：IOPS（每秒操作数）、吞吐（MB/s）、延迟；它们不是独立的——小块卡 IOPS、大块卡带宽，选规格时要同时满足两者，而不是只看 “最大 IOPS”。
三个指标的关系
吞吐 = IOPS × 块大小
例：3000 IOPS × 4KB = 12 MB/s
3000 IOPS × 1MB = 3000 MB/s（实际被带宽上限截断）
| 块大小 | IOPS 3000 时的吞吐 | 瓶颈 |
|---|---|---|
| 4KB | 12 MB/s | IOPS |
| 16KB | 47 MB/s | IOPS |
| 64KB | 188 MB/s | 过渡区 |
| 256KB | 750 MB/s | 带宽 |
| 1MB | 3000 MB/s（理论） | 带宽 |
本机实测（仅示意量级）
4K 写 + fsync 的延迟（本机 NVMe，50 次）：
| 指标 | 值 |
|---|---|
| P50 | 0.02ms |
| P99 | 0.22ms |
| 单线程 IOPS ≈ | 48,000（P50 口径） |
云盘通常远低于这个数（网络存储、多租户共享），所以 “本机测出来的 IOPS” 不能直接当云盘规格；必须按云厂商的规格表 + 实测校准。
选型：先看 “访问模式”，再看规格
| 负载 | 关键指标 | 规格建议 |
|---|---|---|
| 数据库（OLTP） | IOPS + 低延迟 | 高 IOPS 型，块 4–16KB |
| 日志/顺序写 | 吞吐 | 高吞吐型，块 64KB–1MB |
| 大数据扫描 | 吞吐 | 高吞吐型 + 多盘并行 |
| 小文件随机读 | IOPS + 延迟 | 高 IOPS + 缓存 |
# 用 fio 量真实 IOPS/延迟（云上务必在业务时段测，避免被“突发额度”骗）
fio --name=randread --rw=randread --bs=4k --iodepth=32 --numjobs=4 \
--filename=/data/fio.test --size=4G --runtime=60 --time_based \
--output-format=json | jq '.jobs[0].read.iops, .jobs[0].read.clat_ns.percentile'
反模式
| 反模式 | 后果 |
|---|---|
| 只看 “最大 IOPS” 不看块大小 | 实际吞吐被 IOPS 卡死（4K → 12MB/s） |
| 用突发额度评估容量 | 额度耗尽后性能断崖 |
| 单盘跑数据库 + 备份 | 备份把 IOPS 吃光，事务延迟飙升 |
| 忽略队列深度 | 单线程测不出云盘真实能力 |
| 把 “本机 NVMe” 数据当云盘 | 高估 10–100 倍 |
| 不做 P99 延迟监控 | 只看平均，尾部卡顿被掩盖 |
三条铁律
🔑 吞吐 = IOPS × 块大小；两者要同时满足。
🔑 小块看 IOPS、大块看带宽；按访问模式选型。
🔑 规格表 ≠ 实测；上云后必须用真实负载校准。
自检
Q1 为什么 “3000 IOPS 的盘” 在 4K 随机写下只有 12MB/s？
▸ 答案：因为每次操作只搬 4KB：3000 × 4KB = 12MB/s。这不是盘 “慢”，而是 “操作数上限” 限制了小块的吞吐。要更高吞吐，必须增大块（批量合并）或换更高 IOPS 的规格。
Q2 队列深度为什么影响测出来的 IOPS？
▸ 答案：因为单线程串行请求时，IOPS 受 “单次延迟” 限制（IOPS ≈ 1/延迟）；增加队列深度可以让多个请求并行，逼近设备的并发能力。云盘通常需要 iodepth ≥ 32 才能测出标称 IOPS。
Q3 “突发额度（burst）” 会带来什么误判？
▸ 答案：短时间压测会消耗突发额度，读出 “很高的 IOPS”；额度耗尽后跌回基线，生产上表现为 “跑一会儿就变慢”。评估容量必须持续压测（超过额度恢复周期），而不是跑 10 秒。
Q4 数据库盘为什么不能和备份共用？
▸ 答案：因为备份是大块顺序读/写，会占满带宽与 IOPS 队列；数据库需要低延迟的小块随机 IO，两者争抢时数据库延迟飙升。常见做法是 “数据盘 + 日志盘分离 + 备份走独立盘/对象存储”。
Q5 P99 延迟为什么比平均延迟重要？
▸ 答案：因为云盘是多租户共享，尾部延迟受邻居影响：平均值可能很漂亮，P99 却高一个数量级。数据库/在线服务的超时是按 “最慢请求” 触发的，所以要看 P99/P999，而不是平均。
Q6 什么时候该 “多盘并行” 而不是 “换更大规格”？
▸ 答案：当单盘规格到了上限（IOPS/带宽封顶）而需求继续增长时：用多盘做 RAID0/条带，把 IOPS 与带宽叠加。代价是 “单盘故障影响面” 与 “运维复杂度”，需要配合副本/纠删码保证持久性。
Q7 如何判断 “盘是不是瓶颈”？
▸ 答案：看三个信号：await/延迟上升（排队）、%util 接近饱和（机械盘）、应用 P99 与 IO 延迟同步恶化。如果 CPU 不高、IO 延迟高，基本就是盘；如果 CPU 高、IO 不高，先查计算与锁。