Ceph 对象存储空间使用率异常排查流程

最新推荐文章于 2026-08-18 15:56:03 发布

原创最新推荐文章于 2026-08-18 15:56:03 发布 · 274 阅读

3 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

文章目录

前言
1. 先看集群整体使用率
2. 确认副本数是否正常
3. 查看pg分布是否均衡
4. 计算单个对象大小
5. 查看 BlueStore 最小分配粒度
6. 重新计算使用率

前言

最近排查一个Ceph 对象存储集群时，发现一个问题：客户反馈集群使用率偏高。按照三副本粗略计算，业务数据量对应的集群使用率应该在 58% 左右，但实际 ceph df 看到已经到了 70% 多。
一开始怀疑是不是gc垃圾延时清理，数据分布不均，或者某些池占用了额外空间。但实际排查下来，根因更偏向于：RGW 小文件数太多，叠加HDD bulestore 最小分配粒度，导致实际落盘空间明显放大。

1. 先看集群整体使用率

执行 ceph df detail，看到以下结果，这里有几个关键的信息：

集群裸容量：534T
已用裸容量：398T
集群裸盘使用率：74.60%
RGW 数据池逻辑数据量：约 94.6T
RGW 数据池对象数量：约 9.91 亿
RGW 数据池 RAW USED：约 284T

[root@XB-GSYD-WW1-OSS-001 SDS_Admin]# ceph df detail
GLOBAL:
    SIZE     AVAIL     RAW USED     %RAW USED     OBJECTS
    534T      135T         398T         74.63        945M
POOLS:
    NAME                           ID     QUOTA OBJECTS     QUOTA BYTES     USED       %USED     MAX 
    default.rgw.buckets.data       8      N/A               N/A             96942G     73.88        34265G     991810844      945M       965M      9291M         284T         96942G               284T

如果只看三副本，94.6T 业务数据理论上大概占：94.6T × 3 = 283.8T
池里显示的 RAW USED 是 284T，与三副本后接近。所以第一步可以判断：数据池副本数大概率没有异常。

2. 确认副本数是否正常

执行 ceph osd pool ls detail，看到 default.rgw.buckets.data 池的保护策略为 size 3，没问题；

[root@XB-GSYD-WW1-OSS-001 SDS_Admin]# ceph osd pool ls detail
pool 8 'default.rgw.buckets.data' replicated size 3 min_size 2 crush_rule 6 object_hash rjenkins pg_num 1024 pgp_num 1024 last_change 167 fault_tolerant off less_min_size_to_read off flags hashpspool stripe_width 0 application rgw

执行 rados df，计算 2974427889 / 991475963 ≈ 3，也没问题，这说明每个对象基本都是 3 份副本，并没有变成 4 副本，也不是副本异常导致空间暴涨。

[root@XB-GSYD-WW1-OSS-001 SDS_Admin]# rados df
POOL_NAME                  USED   OBJECTS   CLONES COPIES     MISSING_ON_PRIMARY UNFOUND DEGRADED RD_OPS      RD     WR_OPS     WR   SIZE_ACCURACY
default.rgw.buckets.data   96944G 991835049      0 2975505147                  0       0        0  1012075084 12084G 9742974034 102T        96944G

3. 查看pg分布是否均衡

这里取一个使用率最高和最低的OSD，相差大约在4%左右，还好，也可以排除pg分布不均匀的问题。

[root@XB-GSYD-WW1-OSS-001 SDS_Admin]# ceph osd df | sort -nk 8
ID CLASS WEIGHT   REWEIGHT SIZE   USE   AVAIL %USE  VAR  PGS
MIN/MAX VAR: 0.18/1.03  STDDEV: 27.09
reweighting_state : 0
reweight_state : 0
                     TOTAL   534T  398T  135T 74.63
20   hdd 10.91350  1.00000 11175G 8206G 2969G 73.43 0.98  62
57   hdd 10.91350  1.00000 11175G 8611G 2564G 77.05 1.03  65

4. 计算单个对象大小

USED ≈ 94.6T
OBJECTS ≈ 9.91 亿
粗略估算平均对象大小：94.6T / 9.91亿 ≈ 100KB/对象，这个对象大小就比较关键了。对于对象存储来说，100KB 左右的对象属于比较典型的小对象场景。小对象多了以后，Ceph 底层并不是按照对象真实大小精确占用空间，而是会受到 BlueStore 最小分配粒度、对象元数据、RocksDB/BlueFS 等因素影响。

5. 查看 BlueStore 最小分配粒度

执行 ceph daemon osd.6 config show，关键参数

bluestore_min_alloc_size_hdd = 65536

[root@XB-GSYD-WW1-OSS-001 SDS_Admin]# ceph daemon osd.6 config show | grep bluestore_prefer_deferred_size_hdd
    "bluestore_prefer_deferred_size_hdd": "32768",

这里的 65536 单位是字节，换算后就是：65536 bytes = 64KB

也就是说，这个集群的 HDD OSD 上，BlueStore 最小分配粒度是 64KB。
如果一个对象只有 1KB、10KB、几十 KB，底层也可能至少按 64KB 分配。如果一个对象是 100KB 左右，底层很可能按 128KB 这类粒度占用。
简单举例：

10KB 对象 → 可能至少占 64KB
70KB 对象 → 可能占 128KB
100KB 对象 → 可能占 128KB

再叠加三副本，空间放大就比较明显。

6. 重新计算使用率

刚才我们算出单个对象的容量大约为100KB，存到 Ceph 里面可能占用 128KB。100KB/128KB，相当于放大了1.28倍，重新计算使用率：
94.6 * 3 * 1.28 / (523 * 0.95) = 73%，差不多就等于 ceph df 的结果了，原因应该就是这个，不过我认为这并不是 Ceph 的问题，而是我们这套集群没有配置缓存池，如果上层配一个SSD缓存池，SSD的容量粒度是 bluestore_min_alloc_size_ssd = 8KB，做一下bypass分流和IO 合并我想应该会好很多。而且对象存储建议用纠删码，这里用的是三副本，也不太好，太浪费空间了。

希望对你有帮助。

标签

#ceph