性能估算与瓶颈定位
在采购之前就算出这套配置能跑多快，以及第一个瓶颈会出现在哪。
学完这节你能做到
- 按盘、网络、CPU 三条线分别估算上限
- 找出配置中的短板资源
- 解释副本/EC 对写带宽的放大效应
在采购之前就算出它能跑多快
容量能算准，性能只能估。但"估"不等于拍脑袋——分资源算上限，取最小值，就能定位瓶颈。这个方法能回答两个最有价值的问题：
- 这套配置大概能跑多快？
- 第一个撑不住的资源是什么？加钱应该加在哪？
三条线各自的上限
盘
盘的聚合写带宽 = 节点数 × 每节点盘数 × 单盘稳态写带宽
盘的聚合读带宽 = 节点数 × 每节点盘数 × 单盘稳态读带宽
注意两点：用稳态值（L1 讲过，SSD 前 30 秒的数字不算），以及客户端写会被冗余放大：
3 副本：客户端写 1 GB/s → 盘要写 3 GB/s
EC 8+2：客户端写 1 GB/s → 盘要写 1.25 GB/s
所以盘允许的客户端写带宽 = 盘聚合写带宽 ÷ 写放大倍数。
网络
cluster 网承载：副本/分片的转发流量
3 副本 → 客户端写量 × 2
EC 8+2 → 客户端写量 × 1.125
public 网承载：客户端流量 × 1
所以cluster 网允许的客户端写带宽 = cluster 网总带宽 ÷ (副本数 − 1)。
单网共用时，两部分流量挤在一起，允许的客户端写带宽 = 网络总带宽 ÷ 副本数。
CPU 与内存
不直接限制带宽，但会限制 OSD 数量：每 OSD 约 1 核 4~8GB。一台 32 核 256GB 的机器插 48 块盘，CPU 和内存都不够，实际跑起来会因为争抢而严重掉速。
交互估算器
改参数看瓶颈怎么迁移。建议按顺序试这四组：
- 默认配置（8 节点 × 12 盘 × 25GbE 双网 × 3 副本）：先看瓶颈落在哪
- 把 cluster 网改成 0（单网共用）：看写带宽掉多少
- 把冗余从 3 副本换成 EC 8+2：看瓶颈是否从网络转移到盘
- 把每节点盘数从 12 加到 24：看写带宽是否翻倍（多半不会，因为瓶颈已经在网络）
- 数据盘64.00 GB/s
- cluster 网络 ← 瓶颈11.25 GB/s
- public 网络22.50 GB/s
- 数据盘336.00 GB/s
- public 网络 ← 瓶颈22.50 GB/s
- ·单节点盘的聚合带宽远超网卡能力，加盘不会再提升带宽，应先升级网络。
- ·以上为顺序大块带宽估算；随机小 I/O 的上限由 IOPS 和延迟决定，需要单独测量。
加盘不涨带宽，是规划里最常见的钱花错地方的场景。
木桶效应：当瓶颈在网络时，加盘一分钱收益都没有。正确动作是先把 25GbE 升到 100GbE，或者做前后端网络分离。
这就是"分资源算上限"的价值——它能阻止你把钱花在已经不是瓶颈的地方。
随机 IOPS 的估算
带宽估算对大块顺序 I/O 成立。随机小 I/O 要单独算：
集群随机读 IOPS ≈ 单盘 IOPS × 盘数 × 折扣(0.6~0.7)
集群随机写 IOPS ≈ 单盘 IOPS × 盘数 ÷ 副本数 × 折扣(0.5~0.6)
折扣比带宽场景更狠，因为随机小 I/O 要经过完整的软件栈：网络往返、PG 定位、副本协调、BlueStore 事务。Ceph 在随机小 I/O 上的软件开销占比很高，这也是它在全闪配置下性能"普通"的原因——storplan 的选型表里对 Ceph RBD 的描述正是"全闪配置性能普通"。
EC 4+2 下写一个 4KB 对象，要切成 6 个约 1KB 的分片发到 6 个 OSD。这时：
- 网络请求数 ×6
- 每次磁盘写只有 1KB，远低于盘的最优块大小
- 要等最慢的那个 OSD 返回
实测下来 EC 的小写性能可能只有副本的几分之一。估算器给出的 EC 数字，只在大文件顺序写场景下有参考价值。
延迟的估算
带宽和 IOPS 可以算，延迟基本只能靠经验值和实测：
客户端写延迟 ≈ 网络 RTT × 2 + 最慢副本的落盘延迟 + 软件栈开销
全闪 Ceph 的典型值（4K 随机写，队列深度 1）：
| 环节 | 典型耗时 |
|---|---|
| 客户端到 primary OSD 的网络往返 | 50 ~ 100 µs |
| primary 到副本的网络往返 | 50 ~ 100 µs |
| NVMe 落盘 | 50 ~ 150 µs |
| Ceph 软件栈（PG、BlueStore 事务等） | 200 ~ 500 µs |
| 合计 | 约 0.5 ~ 1 ms |
这个数字对虚拟机和大多数数据库够用，但对延迟极度敏感的场景（高频交易、某些实时数据库）就不够了——那类场景要看本地 NVMe 或专门的低延迟方案。
把估算写成结论
估算的产出不是一个数字，而是一句带条件的判断：
## 性能估算结论
配置：8 节点 × 12 × 7.68TB NVMe，2 × 25GbE 前后端分离，3 副本
- 顺序写：约 7.9 GB/s，瓶颈在 cluster 网络（理论上限 11.25 GB/s，打 0.7 折）
- 顺序读：约 18.0 GB/s，瓶颈在 public 网络（理论上限 22.5 GB/s，打 0.8 折）
- 4K 随机读：约 25 万 IOPS（估算，需实测验证）
- 4K 随机写：约 8 万 IOPS（估算，需实测验证）
- 典型写延迟：0.5 ~ 1 ms（P99 可能到 3 ms）
判断：
- 若业务要求写带宽 > 8 GB/s，必须升级到 100GbE，加盘无效（盘侧还有 64 GB/s 余量）
- 若业务以随机小 I/O 为主，建议实测后再定，估算误差可能较大
- 未评估：恢复期间的性能衰减（经验值下降 30% ~ 50%）所有估算都是在集群健康时做的。一块盘坏了触发重建，恢复流量会和业务抢 I/O 和带宽，性能下降 30% ~ 50% 是常态。
如果业务在峰值期只剩 10% 余量，那么任何一次坏盘都会变成业务事故。 规划时要问：能不能接受在恢复期间降速？如果不能，容量和带宽都要留更多余量，或者把恢复限速调到很低（代价是恢复窗口变长，降级状态持续更久）。
8 节点，每节点 12 块盘（单盘写 2 GB/s）、cluster 网 25Gbps。3 副本下，客户端写带宽的瓶颈在哪？
估算器显示写瓶颈在网络。业务要求写带宽再提升一倍，最有效的做法是？
关于性能估算的边界，下面哪些说法正确？（多选）
这节课的落点
- 分资源算上限，取最小值 = 瓶颈定位
- 盘允许的写带宽 = 聚合写带宽 ÷ 写放大；cluster 网允许的 = 网络带宽 ÷ (副本数−1)
- 加盘不涨带宽是常见的钱花错地方，先确认瓶颈在哪
- 随机 IOPS 折扣更狠，EC 的估算只对大块顺序 I/O 成立
- 全闪 Ceph 的典型写延迟 0.5~1 ms，极低延迟场景要另找方案
- 估算结论要带条件和"未评估项"，恢复期性能衰减必须提前说