HDUO Lab

标签： Mmap

  • 深入 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 层面统一配置。

  • RocketMQ 生产环境 P99 抖动排查实战：PageCache 剧烈回收引发的 Broker Busy 与 Mmap 预热机制解析

    排查过程中，某高并发压测场景下的 RocketMQ 集群（v4.9.4）频繁爆出 [TIMEOUT_CLEAN_QUEUE]broker busy，发送延迟 P99 从 5ms 突增至 2000ms+。核心原因是 Linux PageCache 脏页回写与 mmap 缺页中断（Page Fault）阻塞了 Broker 写线程。结论先行：通过开启 RocketMQ 的 warmMapedFileEnable=true 和 transientStorePoolEnable=true，配合下调 OS 内核的 vm.dirty_background_ratio，可彻底斩断内核级阻塞，将 P99 稳定压制在 10ms 以内。

    故障现场与指标观测

    某次大促前夕的全链路压测中，单 Broker 节点 QPS 压到 4w 时，客户端开始出现大量的 MQBrokerException: broker busy 与 RemotingTooMuchRequestException 报错。

    查看 Broker 端 store.log 与 broker.log，满屏如下报错：

    202X-XX-XX XX:XX:XX WARN [SendMessageThread_1] - [TIMEOUT_CLEAN_QUEUE]broker busy, start flow control for a while, period in queue: 205ms, size of queue: 853
202X-XX-XX XX:XX:XX WARN [SendMessageThread_2] - OS page cache busy, osPageCacheBusyTimeOutMills=1000

    调出监控看板：

    1. CPU Load：平时 4-5 左右，故障发生瞬间 Load Average 飙升至 40+。

    2. 磁盘 IO：iostat -xdm 1 显示 await 偶尔飙高，但 util% 只有 50% 左右，磁盘并未彻底被打满。

    3. 内存指标：free -m 显示 buff/cache 占用接近 85%，物理空闲内存（free）极少。

    此时通过 strace -p -T -e trace=mmap,munmap,write,pwrite64 抓取底层系统调用，发现部分写操作耗时极其离谱，甚至超过 1 秒。这就引出了一个经典的架构错觉：我都全异步了，为什么还会卡？

    为什么异步刷盘（ASYNC_FLUSH）依然会阻塞写线程？

    很多开发人员认为，只要 RocketMQ 配置了 flushDiskType=ASYNC_FLUSH，消息只要写到内存（PageCache）就算成功，磁盘 IO 慢绝不会影响发送延迟。这是一个极其致命的认知盲区。

    RocketMQ 的 CommitLog 默认采取 1GB 固定大小，通过 mmap（Memory Mapped Files）将物理文件映射到用户态的虚拟内存中。Broker 处理写请求的核心路径是： SendMessageProcessor -> CommitLog.putMessage() -> MappedFile.appendMessagesInner() -> ByteBuffer.put(data)

    问题就出在这个 ByteBuffer.put() 上。这虽然是内存操作，但在 Linux 内核视角下，它随时可能被阻塞，原因有二：

    1. 缺页中断（Minor/Major Page Fault）： 当 Broker 滚动创建新的 1GB CommitLog 并执行 mmap 时，Linux 采用的是“延迟分配”策略。仅仅是建立了虚拟内存地址映射，并未分配实际物理页。当写线程第一次往这个地址 put 数据时，会触发内核缺页中断，内核需要去寻找空闲物理页并建立页表。如果此时系统物理内存紧张，内核触发直接回收（Direct Reclaim），写线程就会被死死卡住。

    2. PageCache 脏页回写阻塞： 当脏页积累到内核阈值（vm.dirty_ratio，默认 20%）时，Linux 会挂起所有尝试生成新脏页的用户进程，强行同步刷盘。此时你的 ByteBuffer.put() 会直接退化为同步阻塞写。

    深度解析：CommitLog Mmap 与 读写分离预热机制

    为了规避上述内核级别的阻塞，RocketMQ 提供了几项极为核心的防御性存储机制。

    1. 强制预热与内存锁定（warmMapedFileEnable）

    配置 warmMapedFileEnable=true 后，Broker 在创建新的 1GB MappedFile 时，会提前在后台线程中将其填满 0，强行触发所有的缺页中断，真正分配物理内存。 不仅如此，RocketMQ 还会调用 JNA 执行 mlock 和 madvise：

    // 核心源码示意 (MappedFile.java)
LibC.INSTANCE.mlock(pointer, 1024 * 1024 * 1024);
LibC.INSTANCE.madvise(pointer, 1024 * 1024 * 1024, LibC.MADV_WILLNEED);

    mlock 直接告诉内核：“这 1GB 内存你给我锁死在 RAM 里，绝对不允许 Swap 出去！”。这就彻底消除了写消息时发生 Page Fault 的可能性。

    2. 堆外内存写池（transientStorePoolEnable）

    这是应对 PageCache 毛刺的终极武器（仅限异步刷盘有效）。 开启后，RocketMQ 会预先向 OS 申请一块 DirectByteBuffer 内存池（不受 JVM GC 影响，也暂时不进 PageCache）。 写数据路径变为：写请求 -> DirectByteBuffer -> 立即返回客户端成功。 后台 CommitRealTimeService 线程定期将 DirectByteBuffer 的数据写入 FileChannel（进入 PageCache），再由 FlushRealTimeService 线程异步刷盘。 这是一种极致的读写分离策略，彻底将“接收消息的写线程”与“PageCache 分配/刷盘”解耦。

    极客实战：RocketMQ 存储与内核参数双向调优

    解决此类抖动问题，绝不能只改应用配置，必须深入 OS 层联动调优。以下是我在生产环境经过验证的黄金配置标准。

    RocketMQ 核心配置 (broker.conf)

    # 强制使用异步刷盘
flushDiskType=ASYNC_FLUSH
# 开启堆外内存池缓冲，彻底解耦写请求与PageCache抖动
transientStorePoolEnable=true
# 开启Mmap预热与内存锁定，消除运行时缺页中断
warmMapedFileEnable=true
# 优化PageCache锁超时机制（如果发生抖动，快速失败，依赖重试）
osPageCacheBusyTimeOutMills=1000

    Linux 内核 IO 参数调优 (/etc/sysctl.conf)

    光配 Broker 不够，必须改造内核的脏页回写策略：

    # 脏页占总内存的 5% 时，pdflush 后台线程开始异步刷盘（原默认10%）
# 目的：提早刷盘，细水长流，避免积压
vm.dirty_background_ratio = 5

# 脏页占总内存的 40% 时，强制阻塞所有用户态写进程（原默认20%）
# 目的：拉开与 background_ratio 的差距，给突发流量留足 Buffer
vm.dirty_ratio = 40

# 坚决不使用 Swap（避免mmap的内存被换出）
vm.swappiness = 1

# 预留给 OS 应急的物理内存（例如 128G 内存机器配 2G）
# 目的：避免缺页中断时因无空闲内存触发直接回收（Direct Reclaim）引发系统停顿
vm.min_free_kbytes = 2097152

    执行 sysctl -p 生效。经过这一套连招组合拳，压测 P99 稳如泰山，再也没有出现过 broker busy。

    常见问题 (FAQ)

    Q1：开启 transientStorePoolEnable=true 后，如果 Broker 进程直接 Crash（如 OOM Killer），数据会丢失吗？ 会。这就是享受极致低延迟的代价。该模式下数据首先写入 DirectByteBuffer，这是用户态进程的堆外内存。如果进程被 kill -9 或者 Crash，这部分尚未 commit 到 OS PageCache 的数据将会丢失。如果你对数据一致性要求极度苛刻（如金融交易），只能忍受延迟，关闭此项并使用 SYNC_FLUSH。

    Q2：为什么消费重试队列（%RETRY%）里的消息会导致明显的磁盘 IO 升高和 Broker 负载增加？ RocketMQ 是基于 CommitLog 的混合存储。正常消费是顺序读写（刚写完的数据大概率还在 PageCache 中，命中率极高）。但重试队列消费的是过去某个时间点的冷数据。这就迫使 Broker 产生大量的随机 IO（读磁盘），导致 PageCache 污染，驱逐掉热数据，从而引发全局性能下降。应对策略通常是单独隔离重试服务，或使用 NVMe SSD 扛随机 IO。

    Q3：遇到 [TIMEOUT_CLEAN_QUEUE]broker busy，除了存储层问题，还有什么原因？ 如果磁盘 IO 不高，PageCache 也没问题，你需要检查是不是 JVM 发生了长时间的 Stop-The-World (STW)。尤其是 G1 GC 配置不当，或是业务代码向 RocketMQ 发送超大消息（如几 MB 的报文），导致 Broker 在反序列化/网络传输时消耗大量 CPU 和内存资源，阻塞了 Netty 的 Worker 线程。