【咨询】NebulaGraph 3.x 自行编译 RocksDB 开启 io_uring 的相关问题

问答 问题
, ,
1

您好，想咨询关于 NebulaGraph 结合 RocksDB io_uring 的相关问题。
当前使用 NebulaGraph 社区版 3.8，环境为裸金属服务器，Linux 内核 5.15，NVMe SSD。

已知信息：

  1. NebulaGraph 官方预编译包内置的 RocksDB 未启用 io_uring，网络层 RPC 使用 libevent+epoll，仅磁盘 IO 可通过替换 IOURingEnv 改造；
  2. 需要自行编译 RocksDB 开启WITH_IO_URING，再重新编译 NebulaGraph 链接该自定义 RocksDB；

想请教几个问题：

  1. Nebula storaged 多 RocksDB 实例（多 data_path）场景，每个实例单独创建 io_uring ring，是否存在已知稳定性问题、资源泄漏风险？
  2. 在 Raft 复制、Snapshot、Balance 分片迁移场景，RocksDB IOURingEnv 下 WAL fsync/compaction 的错误处理逻辑，社区是否有相关踩坑案例？
  3. 开启 io_uring 后，除内核版本、ulimit 之外，是否有推荐的内核 sysctl 参数、RocksDB option 特殊配置？
  4. 是否有生产环境使用该方案的案例？该改造是否会影响 Raft 数据一致性？

负载背景：业务存在大量冷数据图扫描，block cache 命中率偏低，存在 compaction IO 瓶颈，想评估 io_uring 降低 IO 长尾延迟的收益。

谢谢！