HDUO Lab

标签： CommitLog

  • 深入 RocketMQ 陷阱排查：CommitLog mmap 锁竞争引发的 PageCache 抖动与 Producer 假死实战

    生产环境 RocketMQ 节点频繁出现 Producer 发送超时（RT > 3s）。核心原因是高并发场景下 PageCache 脏页回写引发 mmap 内存锁竞争，导致 CommitLog 异步刷盘退化为同步阻塞。解决方案：开启 transientStorePoolEnable=true 引入 DirectByteBuffer 读写分离，并下调 OS vm.dirty_background_ratio 至 5%，抹平内核 pdflush 抖动。

    近期在主导一个千万级 QPS 核心链路的可用性治理时，遇到了一个极为隐蔽的 RocketMQ 抖动问题。集群版本为 4.9.4，部署在 64C 256G 的物理机上，底层使用 SSD 阵列，Broker 配置为 ASYNC_FLUSH（异步刷盘）加 ASYNC_MASTER。

    监控大盘显示，大部分时间 Producer 写入耗时在 2ms 以内，但在业务高峰期，99 线会毫无规律地飙升到 3000ms 以上，甚至直接触发客户端超时异常 RemotingTooMuchRequestException。

    现场取证与监控排查

    排查初期，先看机器负载。发生抖动时，CPU 使用率不到 30%，内存充足，但 iostat -x 1 捕捉到了异常：磁盘 util% 瞬间打满 100%，await 飙升至几百毫秒。

    查看 Broker 的 store.log 和 broker.log，发现了大量如下报错：

    2023-XX-XX XX:XX:XX WARN [Broker-XX] - [NOTIFYME]page cache is busy, CPUBusyFlag=false, OSPageCacheBusyFlag=true, lock time(ms)=1250

    对应的，由于 PageCache 繁忙，RocketMQ 的快速失败机制被触发，导致向 Producer 返回系统繁忙的错误。使用 jstack 抓取当时的 Broker 线程栈，发现大量 SendMessageThread 被阻塞在 CommitLog.putMessage 方法内部的 putMessageLock 上。

    // 阻塞堆栈片段
"SendMessageThread-1" prio=10 tid=0x00007f... runnable
    at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
    at sun.nio.ch.FileDispatcherImpl.write(FileDispatcherImpl.java:60)
    at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
    ...
    at org.apache.rocketmq.store.CommitLog.putMessage(CommitLog.java:683)

    为什么 ASYNC_FLUSH 模式下依然会阻塞 Producer 线程？

    很多开发者的直觉是：既然配置了异步刷盘（flushDiskType = ASYNC_FLUSH），消息写到内存（PageCache）就会立刻返回，磁盘 I/O 抖动怎么会反向阻塞网络线程？

    要解释这个问题，必须深入 Linux 内核的 mmap 机制以及 RocketMQ 的写入模型。

    RocketMQ 的 CommitLog 默认通过 MappedByteBuffer (基于 Linux mmap 系统调用) 进行文件映射。Producer 写入消息时，本质上是往内存映射地址执行 memcpy。 在正常情况下，写 PageCache 的速度极快（微秒级）。但内核中存在两个关键的脏页回写参数：

    1. vm.dirty_background_ratio：默认 10%。当系统脏页比例达到此值，内核唤醒 pdflush (或 flush 线程) 异步将脏页刷盘。

    2. vm.dirty_ratio：默认 20%。当系统脏页比例达到此值，内核会强制阻塞所有发起写操作的用户线程，进行同步刷盘。

    当瞬间写入吞吐过高，底层 SSD 处于 GC 卡顿或 I/O 队列排队时，脏页积压一旦触达 vm.dirty_ratio 阈值，内核就会对当前的 mmap 写入操作施加阻塞。

    在 RocketMQ 4.9.4 的源码 CommitLog#isOSPageCacheBusy() 中，有一个看门狗机制：

    public boolean isOSPageCacheBusy() {
    // beginTimeInLock 记录了获取自旋锁或 ReentrantLock 的开始时间
    long begin = this.beginTimeInLock;
    // 默认 osPageCacheBusyTimeOutMills 为 1000ms
    long diff = this.systemClock.now() - begin;
    return diff < 10000000 && diff > this.defaultMessageStore.getMessageStoreConfig().getOsPageCacheBusyTimeOutMills();
}

    当系统内核因脏页同步刷盘阻塞了某个正在持有 putMessageLock 的线程超过 1 秒，其他排队等待这把锁的 Producer 请求就会被判定为 page cache is busy 并快速失败。

    架构级调优：启用瞬态存储池 (TransientStorePool)

    要彻底根治这个问题，就必须把消息的“写入”和“PageCache分配/刷盘”在物理内存层面隔离开来。RocketMQ 提供了 transientStorePoolEnable 机制，这也是解决高并发下 PageCache 抖动的终极杀器。

    修改 broker.conf：

    flushDiskType=ASYNC_FLUSH
transientStorePoolEnable=true
# 瞬态池大小配置，按需调整（默认 5 个 CommitLog 文件的容量，即 5G）
transientStorePoolSize=5

    底层原理解析： 开启后，RocketMQ 启动时会通过 posix_memalign 调用（Java 层为 ByteBuffer.allocateDirect 并利用 JNA 锁定内存 mlock）向系统申请一块堆外直接内存（DirectByteBuffer）作为瞬态池。

    此时消息的写入流转变为：

    1. Producer 写入 (极速且稳定)：业务线程直接将数据拷贝到 DirectByteBuffer（完全在用户态，绕过 PageCache，绝对不会触发内核的同步刷盘阻塞），随后立即返回成功。

    2. Commit (异步)：CommitRealTimeService 线程异步将 DirectByteBuffer 中的数据写入 FileChannel (即进入 OS PageCache)。

    3. Flush (异步)：FlushRealTimeService 线程再异步将 PageCache 强制 fsync 到磁盘。

    引入这层真正的内存缓冲后，即便底层磁盘发生 3-5 秒的严重卡顿，只要 DirectByteBuffer 没写满，上游 Producer 线程依然可以保持微秒级的响应，实现了真正的系统级削峰填谷。

    操作系统内核参数的防御性加固

    除了架构层面的隔离，操作系统层面的调优也是必须的。默认的脏页回写策略过于激进，容易造成“平时不刷盘，一刷盘就卡死”的突刺现象。

    编辑 /etc/sysctl.conf：

    # 降低后台异步刷盘触发阈值，让内核更频繁、平缓地刷盘 (默认10)
vm.dirty_background_ratio = 5

# 适当调高同步阻塞刷盘阈值，给瞬时高峰留出更大缓冲空间 (默认20)
vm.dirty_ratio = 40

# 缩短脏页过期时间，单位百分之一秒，1000 即 10 秒 (默认3000)
vm.dirty_expire_centisecs = 1000

# 禁用 NUMA 架构下的内存交叉分配，防止 kswapd 频繁回收抖动
vm.zone_reclaim_mode = 0

    执行 sysctl -p 立即生效。配合 transientStorePoolEnable=true 后，集群 99 线尖刺完全消失，大促压测期间 QPS 单机突破 8 万依然如丝般顺滑。

    常见问题 (FAQ)

    Q1: 开启 transientStorePoolEnable=true 后，Broker 宕机会不会丢消息？ 会。这是典型的 CAP 权衡。停留在 DirectByteBuffer 里的消息（还未进入 PageCache）在 Broker 进程崩溃（OOM 或被 kill -9）时会丢失；而如果只是写入了 PageCache 但未刷盘，进程崩溃不会丢，只有物理机断电才会丢。此方案适用于允许极少量消息丢失以换取极致延迟和吞吐的业务场景（如日志、非核心流水）。若涉及金融级交易链路，请老老实实关闭此配置，使用 SYNC_FLUSH 并搭配高性能 NVMe SSD。

    Q2: 为什么调整了 vm.dirty_ratio 还是偶尔报 page cache is busy？ 必须首先排查底层磁盘的 IOPS 是否已经达到硬件瓶颈（或云盘的限流阈值）。如果物理盘的写入速度长线远低于集群的消息生产速度，调整内存参数只不过是延缓了系统死亡的时间。利用 iostat 确认底层 I/O 是偶尔的 latency spike 还是持续的 utilization 100%。

    Q3: 顺序消息场景下，触发 PageCache 繁忙会导致什么严重后果？ 如果是普通消息，快速失败后 Producer 客户端会自动重试其他 Broker；但在严格顺序消息场景下（MessageQueue 选择是固定的），一旦该 Broker 发生内存锁阻塞，Producer 针对该队列的重试大概率依然落在同一个 Broker 上，导致整条顺序链路在数秒内处于完全停滞状态，引发上游业务线程池被打满挂起。

    Q4: 云原生容器化部署时，如何配置这些内核参数？ 如果 RocketMQ 跑在 K8s 中，vm.dirty_ratio 等属于内核级 sysctl 参数，不能在普通的 Pod 级别直接设置。需要开启 Pod Security Policies (或对应的安全准入控制)，允许 unsafe sysctls，并在 Pod Spec 的 securityContext.sysctls 中显式声明。若安全策略不允许，只能在宿主机 Node 层面统一配置。