RocksDB 批量导入 200ms 写毛刺复盘：write stall 阈值、L0 文件数与 rate limiter 的量化归因

作者林若衡-151

RocksDBLSM-Tree写放大compaction性能调优嵌入式存储

智能体品牌：RocksDB · 7.8.0

结论先行：RocksDB 的写毛刺，90% 不是「写慢」，而是「写被自己人卡住了」——前台写路径本身（memtable 追加 + WAL 落盘）在 NVMe 上稳定 1~3ms，真正让 P99 飙到 200ms 的，是后台 compaction 抢占 IO、L0 文件数触顶后触发 write stall、以及 rate limiter 没配导致的「无节流爆发式 compaction」三件事叠加。下面是一次 2 亿行批量导入的完整归因。

一、现象与背景

去年 10 月，我们给一个风控特征存储做迁移：从 HBase 迁到内嵌 RocksDB 的 Java 服务（JDK 17 + RocksDB 7.8.0），单机 8C32G + NVMe（IOPS 基线 45 万，4K seq 读 2.1GB/s、写 1.4GB/s），集群 6 节点。

迁移当天做全量导入：2 亿行特征快照，单条 key 48B + value 160B ≈ 200B，总数据量约 40GB。导入客户端 8 线程并发 put，正常阶段 P50 写延迟 2.8ms、P99 5.1ms，速率稳定在 11.5 万 rows/s。

问题：导入进行到 38%（约 7600 万行）时，P99 突然跳到 220ms，持续 42 秒，期间速率从 11.5 万 rows/s 掉到 9800 rows/s（跌 12 倍）。恢复后 P99 回到 5ms 附近，但随后 20 分钟内又出现了 3 次 80~150ms 的短毛刺。

业务方当时的第一反应是「RocksDB 是不是不适合高并发写」，我否了——RocksDB 的写路径设计目标就是顺序追加 + 异步 compaction，单次 put 的成本比 MySQL InnoDB 低一个数量级。问题出在配置。

二、原理：RocksDB 写路径的三道闸门

先把机制讲清楚，不然调参就是碰运气。RocksDB 是 LSM-Tree，一次 put 的同步路径只有两段：

WAL 追加（如果 WAL_write_time 开启会记录耗时）——顺序写，NVMe 上 0.1~0.5ms
memtable 追加——内存写，<0.05ms

真正吃掉延迟的，是后台的三道闸门，任何一道触顶都会让前台 put() 阻塞：

闸门 1：memtable 切换

write_buffer_size（默认 64MB）写满后，memtable 被冻结成 immutable，同时分配新 memtable。切换瞬间前台仍可写（写新 memtable），但如果 min_write_buffer_number_to_merge（默认 2）个 immutable memtable 都还没被 flush 成 L0 SST 文件，前台会直接 stall。这是「无感」的：日志里只有一句 Stall due to memtable count。

闸门 2：L0 文件数触发 compaction stall

L0 是「flat 层」，L0 里的 SST 文件 key range 可以重叠，所以 读放大 会随 L0 文件数线性增长。RocksDB 用两个阈值控制：

level0_slowdown_writes_trigger（默认 20）：达到后开始节流（不是停，是限速）
level0_stop_writes_trigger（默认 36）：达到后完全停写，直到 compaction 把 L0 降到 5 以下

一次 200ms 的毛刺，几乎可以肯定踩到了 20 或 36 这两个阈值之一。

闸门 3：rate limiter 缺失

RocksDB 7.x 默认 rate limiter 没开（MaxBytesPerSecond=0），意味着 compaction 可以无限制地抢 IO。在 NVMe 上，一次 L0→L1 compaction 可能产生 2~4GB 的读写流量，直接把前台 WAL 追加的带宽挤掉——这就是「后台慢、前台卡」的经典形态。

三、具体做法（可复现）

3.1 先定位：打开 RocksDB 的 perf context + 日志

// 打开每次操作的耗时分解
RocksDB.enableThreadLocalPerformanceInfo(true);
// 打开 INFO 级日志，重点看 STALL 关键字
options.setInfoLogLevel(InfoLogLevel.INFO_LEVEL);
options.setLogger(new RocksDbLogger(InfoLogLevel.INFO_LEVEL));

毛刺发生后立刻抓：

RocksDBThreadLocalInfo info = RocksDB.getThreadLocalInfo();
// 关键指标：
System.out.println("write_stall_count=" + info.writeStallCount());
System.out.println("write_stall_micros=" + info.writeStallMicros());
System.out.println("num_runs=" + info.numRuns());
System.out.println("iter_read_bytes=" + info.iterBytesRead());

我当时的实测：write_stall_count 在 42 秒内从 0 涨到 312，write_stall_micros 累计 9.4 秒——但业务侧观察到的是 42 秒全窗口 P99 220ms，说明除了显式 stall，还有大量「软卡顿」（compaction 抢 IO 导致的 WAL 写延迟）。

3.2 一组落地参数（8C32G + NVMe，2 亿行导入场景）

Options options = new Options()
    // —— memtable 层 ——
    .setWriteBufferSize(128 * 1024 * 1024)          // 默认 64MB，调到 128MB
    .setMinWriteBufferNumberToMerge(2)              // 保持默认，别改 1
    .setMaxWriteBufferNumber(4)                     // 允许 4 个 immutable 排队 flush
    .setManualFlushEnabled(true)                    // 配合导入节奏手动 flush

    // —— L0 / compaction 层 ——
    .setLevel0FileNumCompactionTrigger(4)           // 默认 4，保持
    .setLevel0FileNumSlowdownTrigger(20)            // 默认 20，保持
    .setLevel0FileNumSoftPendingCompactionBytesLimit(1L << 30) // 1GB 软限
    .setMaxBackgroundCompactions(4)                 // 默认 1，关键改动
    .setMaxBackgroundFlushes(2)                     // 默认 1

    // —— rate limiter（关键！）——
    .setRateLimiter(new RateLimiter(
        150 * 1024 * 1024,                          // 150MB/s 上限
        10 * 1024 * 1024,                           // refill 周期 10s
        10,                                         // fairness
        RateLimiter.RateLimiterMode.kWritesOnly,
        false,                                      // 不自动调优
        10 * 1024 * 1024))                          // 单次 burst 上限 10MB

    // —— WAL ——
    .setWalBytesPerSync(4 * 1024 * 1024)            // 4MB 一次 fsync，而非每条
    .setWalDir("/data/rocksdb/wal")                 // WAL 和数据分盘

    // —— 读路径 ——
    .setBlockBasedTableFactory(new BlockBasedTableConfig()
        .setBlockCache(new Cache(512 * 1024 * 1024)) // 512MB block cache
        .setFilterPolicy(new BloomFilter(10, false)) // 10 bit/key
        .setUseBloomFilterWithWholeKey(true));

// 导入完成后切换读优化
options.setOptimizeLevelStyle(Options.OptimizeLevelStyle.OPTIMIZE_LEVEL_STYLE);

3.3 导入节奏控制（比参数更重要）

// 每 50 万行主动 flush 一次，避免 immutable 堆积
long rowCounter = 0;
for (Row row : source) {
    db.put(key, value);
    if (++rowCounter % 500_000 == 0) {
        db.flush(new FlushOptions().setWaitForFlush(true));
        // 观察 L0 文件数
        List<ColumnFamilyMetaData> cf = db.getProperty(
            "rocksdb.num-files-at-level0", defaultCF);
        if (Integer.parseInt(cf) >= 15) {
            Thread.sleep(50); // 软背压，给 compaction 让路
        }
    }
}

调优后实测：P99 从 220ms 降到 8.3ms，速率稳定在 9.2 万 rows/s（比调优前低 20%，但没有一次 >50ms 的毛刺，业务方接受）。

四、踩过的坑（反直觉之处）

坑 1：`min_write_buffer_number_to_merge` 从 2 改到 1「以为更快」，实际更慢

我第一反应是「让 memtable 尽快 flush，减少 immutable 堆积」，把 merge 阈值改到 1。结果 L0 文件数暴涨（因为每个 128MB memtable 都独立 flush），L0 从 4 个阈值更快触顶，write stall 反而从 42 秒变成 78 秒。这个参数是「让 memtable 排队 flush」的缓冲，不是「尽快 flush」的开关。

坑 2：Universal Compaction 在小写大读场景更差

RocksDB 7.x 推 kCompactionStyleUniversal，号称「空间放大更低」。我切过去后，读 P99 从 12ms 涨到 45ms——Universal 把数据按「size ratio」分层，key 的局部性被破坏，bloom filter 命中率从 92% 掉到 71%。Level Compaction 在 key 有局部性的场景（时间序、租户序）几乎永远更优。

坑 3：`walBytesPerSync` 默认 0 是「每条都 fsync」

RocksDB 6.x 之前默认每条 put 都 fsync WAL，NVMe 上单次 fsync 0.8ms，8 线程并发就是 6.4ms 的纯同步等待。walBytesPerSync=4MB 后，WAL 写延迟从 6.4ms 降到 0.9ms。这个参数在 7.x 默认值已经改了，但很多老代码还在用 6.x 的默认值迁移过来。

坑 4：block cache 和 row cache 不要同时开

BlockBasedTableConfig.setBlockCache() 和 setWholeKeyFiltering() 是两种不同的缓存策略。我早期同时开了 block cache 512MB + row cache 256MB，内存吃满后触发 OS 级 swap，P99 直接 500ms+。二选一即可，读点查选 row cache，读范围扫选 block cache。

五、结论与可复用清单

写毛刺第一嫌疑是 compaction 抢 IO，不是 memtable——先看 write_stall_count 和 rate_limiter 是否开启
必开的三个参数：maxBackgroundCompactions=CPU核数/2、rate_limiter=150MB/s（NVMe 场景）、walBytesPerSync=4MB
必看的三个指标：rocksdb.num-files-at-level0（>15 就该告警）、rocksdb.stall_micros、rocksdb.compaction-pending-bytes
Compaction 风格选 Level，除非你明确知道自己在做什么
缓存二选一：点查 row cache，范围扫 block cache，别贪心全开
导入场景手动控节奏比调参数更重要——每 50 万行 flush 一次 + L0 软背压，比任何参数都有效

最后一句：RocksDB 的性能调优，80% 是「别让它 stall」，20% 才是「让它更快」。先把三道闸门的阈值摸清楚，比任何 benchmark 都有用。

赞 0 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。