共计 1528 个字符，预计需要花费 4 分钟才能阅读完成。

背景痛点

4 卡 GPU 服务器在分布式存储场景下常面临以下性能瓶颈：

• PCIe 带宽竞争：当 4 块 GPU 同时通过 PCIe 总线访问存储时，带宽争抢导致吞吐下降。SPECstorage 测试显示，典型场景下 PCIe 3.0 x16 总带宽利用率仅达 60%
• NVLink 利用率不足：GPU 间 NVLink 通道未充分用于数据交换，导致跨节点通信频繁
• 存储延迟波动：本地 SSD 与网络存储混合使用时，尾部延迟可能相差 10 倍以上

技术选型

对比主流分布式存储系统在 GPU 环境的表现：

选择 Ceph+RBD 的原因：

1. RBD 块设备天然适配 GPU 计算框架
2. CRUSH 算法可定制数据分布策略
3. 社区对 RDMA 的支持较成熟

核心实现

数据分片算法优化

修改 CRUSH Map 实现 GPU-aware 数据分布：

# crushmap.txt
device 0 osd.0 class ssd  # GPU0 本地 SSD
device 1 osd.1 class nvme # GPU1 本地 NVMe

rule gpu_rule {
    ruleset 1
    type replicated
    min_size 1
    max_size 3
    step take default class ssd  # 优先选择同 GPU 的 SSD
    step chooseleaf firstn 1 type host
    step emit
}

RDMA 网络层改造

使用 Go 语言实现 verbs 通信核心逻辑：

// rdma_transfer.go
func sendViaRDMA(buf []byte, qp *ibv.QP) error {
    wr := ibv.SendWr{
        Opcode:   ibv.IBV_WR_RDMA_WRITE,
        Send_flags: ibv.IBV_SEND_SIGNALED,
        Num_sge: 1,
        Sg_list: []ibv.Sge{{Addr: uint64(uintptr(unsafe.Pointer(&buf[0]))),
            Length: uint32(len(buf)),
            Lkey: mr.Lkey,
        }},
    }
    return postSend(qp, &wr) // 错误处理略
}

一致性哈希环优化

动态负载均衡策略：

1. 实时监测 OSD 响应时间
2. 当某个 OSD 延迟 > 阈值时自动降低其权重
3. 新增 OSD 时渐进式提升权重

性能验证

Fio 测试对比

测试参数：

[global]
ioengine=libaio
direct=1
runtime=300

[randread]
rw=randread
bs=4k
depth=32

优化前后 IOPS 对比：

网络延迟监控

PromQL 查询示例：

avg(rate(ceph_osd_op_r_latency_sum[1m])) 
by (instance) / 
avg(rate(ceph_osd_op_r_latency_count[1m]))

避坑指南

共享内存锁竞争

使用 perf 定位热点：

perf record -F 99 -g -p `pidof ceph-osd` -- sleep 30
perf report --no-children

典型优化点：
– 将 ceph::unordered_map 替换为分片哈希表
– 减少 Buffer::lock 的持有时间

掉盘处理策略

1. 设置 osd_recovery_max_active=8 加速恢复
2. 优先重建 PG 中热数据部分
3. 启用 bluestore_fsck_on_mount 防止元数据损坏

延伸思考

未来可尝试的优化方向：

1. WAL 日志压缩：对 RocksDB 的 WAL 启用 Zstd 压缩
2. 智能预取：基于 GPU 计算模式预测数据访问模式
3. 混合持久内存：将元数据存储在 PMEM 中