瓶颈定位的路径
Ceph 性能问题很少出在「Ceph 本身」，而是某一层先到极限：客户端并发不足、网络带宽打满、OSD 后端盘 IO 饱和、PG 数不合理导致的分布倾斜。定位思路是分段测量：先在客户端压测得到上限，再对比单 OSD 与后端磁盘的实际数据，谁的资源先到顶就是瓶颈层。
基本信息
| 适用平台 | Ceph 集群（所有主流版本） |
|---|---|
| 客户端压测 | rados bench，可区分写、顺序读与随机读 |
| 服务端观察 | ceph osd perf、iostat、网络接口吞吐 |
| 权限要求 | 压测需可写专用池的身份，观察可用只读身份 |
典型使用场景
- 新集群验收：按写入、顺序读、随机读三段测出基线
- 业务变慢：判断是集群整体下降还是单个业务池被挤占
- 扩容前后对比：验证新增节点是否真的带来线性提升
- 参数调整评估：改 PG 数或多活 MDS 前后做同条件复测
分段压测
分段压测
rados bench -p testpool 60 write --no-cleanup # 写测试，保留对象用于读测
rados bench -p testpool 60 seq # 顺序读
rados bench -p testpool 60 rand # 随机读
rados -p testpool cleanup # 清理测试对象
ceph osd perf | sort -k3 -n | tail # 找延迟最高的 OSD瓶颈特征对照
| 瓶颈层 | 观察到的特征 | 处理方向 |
|---|---|---|
| 客户端 | 集群空闲但吞吐上不去 | 加大并发、检查客户端网卡与内核参数 |
| 网络 | 接口带宽接近线速，延迟上升 | 拆分公网与集群网、升级链路 |
| OSD 后端 | 单盘 util 接近满，apply 延迟高 | 换盘或分流热点，核查raid卡缓存策略 |
| 分布倾斜 | 个别 OSD 负载远高于其他 | 检查 CRUSH 规则与 PG 分布是否均衡 |
压测必须固定条件复测：并发数、对象大小、池的副本数与 PG 数都会明显改变结果，混着比等于没有基线。
不要在生产池上做破坏性压测；测试对象未清理会占用容量并干扰后续容量水位判断。
按顺序排除
- 先确认客户端侧资源是否够用：并发数、CPU、网卡是否打满
- 再看存储网络是否接近线速，延迟是否异常抬升
- 接着看单 OSD 与单盘延迟是否明显高于集群平均
- 最后检查数据分布是否倾斜，个别节点承担了过多负载
- 每一步都以采集到的数据为依据，不靠感受下结论
慢请求告警里通常指明涉及的对象与 OSD，先顺着它缩小范围，比从全局开始盲查快得多。