RocksDB + ZenFS on ZNS SSD：从理论到生产的调优实战笔记

最近半年在负责一个海量 KV 存储集群的硬件升级，目标是把单机存储密度从 16TB 提升到 64TB，同时保持 P99 写入延迟 < 10ms。在传统 NVMe SSD 上，RocksDB 的写放大（Write Amplification）随着数据量增长会迅速恶化，后台 Compaction 带来的 IO 抖动简直是噩梦。最终选型落在了 ZNS（Zoned Namespace）SSD 配合 ZenFS 的方案上。

这篇文章不会讲 ZNS 的基础概念（假设你已经了解 Zone Append、Finish、Reset 这些操作），而是直接分享我们在 Intel D7-P5520 ZNS 模式下的实测调优经验，包括那些官方文档不会告诉你的坑。

架构层面的关键认知

ZenFS 并不是传统意义上的文件系统，而是一个 RocksDB 的 FileSystem 插件，直接把 ZNS 的 Zone 抽象成 RocksDB 的 SST 文件容器。这意味着：

• 没有 page cache 干扰：ZenFS 默认使用 Direct IO，避免了内核缓冲区的双重拷贝
• 顺序写入保证：ZNS 的 append-only 特性天然契合 RocksDB 的 WAL 和 SST 写入模式
• 垃圾回收 offload：把 SSD FTL 层的 GC 逻辑上移到应用层，RocksDB 的 Compaction 本身就是 GC

但代价是：你必须手动管理 Zone 的生命周期，且 RocksDB 的随机读性能会受限于 ZNS 的读限制（虽然影响比想象中小）。

环境配置 checklist

我们的测试机型配置：

• 硬件：Intel D7-P5520 7.68TB（ZNS 模式，Zone Size 1.5GB，Total Zones ~4800）
• 内核：Linux 5.15+（必须支持 ZNS 的 nvme-cli 工具）
• RocksDB：v8.9.1（编译时开启 -DWITH_ZENFS=ON）
• ZenFS：随 RocksDB 源码编译，zonefs 后端

编译 RocksDB 时的关键 CMake 选项：

cmake -DWITH_ZENFS=ON \
      -DWITH_SNAPPY=ON \
      -DWITH_ZSTD=ON \
      -DPORTABLE=OFF \
      -DCMAKE_BUILD_TYPE=Release ..

坑点 1：默认的 zenfs 工具需要链接 libzbd，如果系统里的 libzbd-dev 版本低于 1.5.0，会出现 Zone Finish 操作hang 住的情况。建议直接从源码编译最新版 libzbd。

核心调优参数详解

1. ZenFS 层参数

通过 zenfs mkfs 和 rocksdb 的 DBOptions 传递：

关键发现：finish_threshold 是调优甜蜜点。我们测试发现设置为 5 时，Compaction 导致的 Zone Reset 频率过高，SSD 控制器忙于擦除；设置为 20 时，空间利用率只有 75% 左右。10 是平衡写入性能和空间利用的最优解。

2. RocksDB 层参数

DBOptions db_opt;
db_opt.use_direct_reads = true;      // 必须开启，绕过 page cache
db_opt.use_direct_io_for_flush_and_compaction = true;

ColumnFamilyOptions cf_opt;
cf_opt.write_buffer_size = 256 * 1024 * 1024;  // 256MB memtable
cf_opt.max_write_buffer_number = 4;
cf_opt.target_file_size_base = 128 * 1024 * 1024; // 128MB SST
cf_opt.level0_file_num_compaction_trigger = 4;
cf_opt.level_compaction_dynamic_level_bytes = true;

// ZNS 特有关键：增大 SST 大小减少 Zone 碎片化
cf_opt.target_file_size_multiplier = 2;

坑点 2：write_buffer_size 不能太大。虽然 ZNS 支持高并发顺序写，但单个 memtable flush 如果超过 Zone Size（1.5GB），ZenFS 会将其拆分为多个 Zone 写入，反而增加元数据开销。建议保持单个 SST 文件大小在 64MB-256MB 之间。

3. Compaction 策略调整

ZNS 的最优 Compaction 策略与传统 SSD 不同。我们实测发现：

• 禁用 Tiered Compaction：ZNS 不需要考虑冷热数据分层，因为不存在 SSD 层面的 GC 放大
• 增大 max_bytes_for_level_base：设为 1GB（约 666 个 Zones），减少 L0->L1 的 Compaction 频率
• 调整 num_levels：设为 4 而非默认 6，降低深度 Compaction 带来的 Zone Reset 开销

性能基准对比

使用 db_bench 的 fillrandom 和 readrandom 测试，数据集大小 2TB：

意外收获：由于 ZenFS 避免了 FTL 的 GC，在持续写入 24 小时后，传统 SSD 的延迟开始出现毛刺（>100ms），而 ZNS 方案保持稳定。这对于需要持续高吞吐的日志存储场景是质变。

生产环境踩坑记录

坑 3：Zone Reset 的延迟抖动

RocksDB 的 Delete 操作在 ZenFS 下并不会立即释放 Zone 空间，必须等到 Compaction 完成且 Zone 内所有数据都失效后，才能 Reset。如果业务是大量随机删除（如消息队列的 TTL 过期），会出现"僵尸 Zone"——即逻辑上已删除，但物理上仍占用空间。

解决方案：实现自定义的 TTL Compaction Filter，并配合 zenfs 工具的 list 和 reset 命令做离线清理。我们在业务低峰期（凌晨 3 点）跑定时任务，强制 Reset 无效 Zone，回收空间。

坑 4：备份与快照的噩梦

ZenFS 不支持传统的文件级拷贝（cp 命令无效，因为 SST 文件是 Zone 的抽象）。必须使用 zenfs backup 和 zenfs restore 工具，且备份过程会锁定数据库只读。

** workaround**：我们在应用层实现了双 Buffer 机制，主库写 ZNS，备库用传统 SSD，通过 RocksDB 的 BackupEngine 增量同步。虽然成本略高，但保证了数据可靠性。

坑 5：监控缺失

传统的 iostat 无法看到 ZNS 特有的指标（Open Zones 数量，Finish/Reset 延迟）。必须使用 nvme zns report-zones 命令或编写 eBPF 工具采集。

我们写了个简单的 Python 脚本对接 Prometheus，核心逻辑：

# 监控 Open Zones 使用率，超过 80% 报警
zones = subprocess.check_output(["nvme", "zns", "report-zones", "/dev/nvme0n1", "-o", "json"])
open_zones = sum(1 for z in json.loads(zones) if z["zs"] == "ZSEO")

可复用的配置模板

如果你准备直接上生产，这是经过我们验证的 rocksdb.ini 核心片段：

[DBOptions]
use_direct_io_for_flush_and_compaction=true
use_direct_reads=true
max_open_files=-1
zenfs_finish_threshold=10
zenfs_max_open_zones=14

[CFOptions "default"]
write_buffer_size=268435456
max_write_buffer_number=4
target_file_size_base=134217728
level0_file_num_compaction_trigger=4
level_compaction_dynamic_level_bytes=true
compression=kZSTD

总结

ZNS SSD + ZenFS + RocksDB 的组合，在写密集型、顺序写为主、大容量存储场景下，相比传统方案有显著优势（3-5 倍的写放大降低）。但生态仍显稚嫩：缺少成熟的快照方案、监控工具链薄弱、对随机删除不友好。

建议先从冷数据存储、日志归档、时序数据库这类 Append-only 场景试点，不要直接替换在线事务数据库。随着 Linux 内核 6.x 对 ZNS 的支持完善，以及 SPDK 用户态驱动的成熟，这套方案有望成为下一代高性能存储的标准范式。

如果你也在做类似的落地，欢迎交流 Zone 管理策略和 Compaction 调参经验。