HDUO Lab

分类： 性能调优实战

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

  • 深入 Go 服务 CPU 雪崩排查：热路径正则编译引发的 GC 风暴与 pprof 火焰图实战

    排查过程中，业务团队反馈某核心 Go 微服务在流量高峰期随机出现 P99 延迟从 15ms 暴涨至 2.5s，伴随 Pod CPU 利用率打满（Load Average 飙升至 40+，单 Pod 16 核）。研发的第一反应是 K8S 集群节点超卖引发了严重的 CPU Throttling，甚至提工单要求紧急扩容两倍实例。

    拿到现场后，初步排查结论直接打脸：根本不是底层宿主机资源争抢的问题。真实罪魁祸首是研发在处理高频字符串校验的 HTTP 接口热路径中，错误地将 regexp.MustCompile 写在了请求处理函数内部。高达 12,000 的 QPS 导致应用在每次请求时都在疯狂分配内存、重绘正则状态机，引发海量小对象堆积，进而触发 Go runtime 的 gcAssistAlloc 惩罚机制，导致业务 Goroutine 被迫停顿去执行垃圾回收，最终引发全局雪崩。

    案发现场：CPU 与延迟的死亡螺旋

    看监控面板，典型的性能雪崩特征：

    1. CPU 饱和：Pod CPU 使用率长时间顶在 95% 以上，K8S container_cpu_cfs_throttled_periods_total 指标确实在狂飙，说明确实被限流了。

    2. 延迟劣化：P99 延迟与 CPU 使用率呈高度正相关，且呈波浪形锯齿状抖动。

    3. 内存无明显泄漏：RSS 内存水位虽然有波动，但没有持续上涨（没有 OOM 风险），说明对象最终还是被回收了。

    面对这种“CPU 打满、内存没爆”的场景，靠猜业务逻辑无异于大海捞针，必须直接上 Profiling 工具进行降维打击。

    深入底层：从 perf 到 pprof 的链路追踪

    1. 宿主机视角：内核态在忙什么？

    为了排除底层系统环境问题，直接登录到 Pod 所在的宿主机，找到对应的业务进程 PID，掏出 Linux 性能分析的老伙计 perf 看一下全局开销：

    # 采集 10 秒钟该进程的 CPU 事件栈
perf record -F 99 -p <PID> -g -- sleep 10
perf report -n --stdio

    在输出的内核态调用栈中，看到了令人不安的一幕： 超过 20% 的 CPU 时钟周期耗费在内核的 clear_page_erms 和 page fault 相关的自旋锁 _raw_spin_lock 上。这说明进程在疯狂地向操作系统申请新内存页，触发了密集的缺页中断。这绝对不是一个纯粹的计算密集型（CPU-bound）业务该有的表现，这是典型的“伪计算密集”——大量的 CPU 算力被用来做内存分配和垃圾回收了。

    2. 应用视角：揪出用户态的“吸血鬼”

    确认是应用自身的内存分配行为异常后，切入 Go 运行时的 pprof 抓取现场。利用业务早就注册好的 net/http/pprof 端点，直接在容器内拉取 CPU Profile 数据：

    curl -o cpu.prof http://127.0.0.1:8080/debug/pprof/profile?seconds=15

    将 cpu.prof 拉到本地，使用 go tool pprof 启动可视化 Web 界面生成 FlameGraph（火焰图）：

    go tool pprof -http=:8081 cpu.prof

    打开浏览器看着那张宽阔的火焰图，真相一目了然： 在整个 CPU 耗时的宽度中，业务侧真实的 CRUD 逻辑只占了不到 10%。一个巨大无比的“平顶山”占据了超过 60% 的屏幕宽度，山峰的调用栈层级清晰地写着： YourBusinessHandler -> regexp.MustCompile -> regexp.compile -> syntax.Parse -> runtime.mallocgc。

    而在火焰图的另一侧，赫然立着另一座高山： runtime.gcBgMarkWorker 和 runtime.gcAssistAlloc。

    灾难原理解析：动态编译与 gcAssistAlloc 惩罚

    很多习惯了写脚本语言的开发者，往往对正则引擎的底层开销缺乏敬畏。在 Go 语言中，regexp.Compile 或 MustCompile 是一个极度重度的操作。它需要：

    1. 解析正则表达式字符串（AST 树构建）。

    2. 将抽象语法树编译为一系列指令。

    3. 构建并分配庞大的状态机对象来执行匹配。

    如果把这行代码放在 HTTP Handler 里：

    func UserInfoHandler(w http.ResponseWriter, r *http.Request) {
    // 愚蠢的写法：每次请求执行编译
    re := regexp.MustCompile(`^[a-zA-Z0-9_]{5,20}$`) 
    if !re.MatchString(r.FormValue("username")) {
        // ...
    }
}

    在 QPS 破万的场景下，这意味着每秒钟要发生 1 万次复杂对象的分配。

    Go 的 GC 惩罚机制（Mark Assist）是如何引爆雪崩的？ Go 的垃圾回收器是并发标记清除模型（Concurrent Mark Sweep）。为了防止业务 Goroutine 分配内存的速度超过后台 GC 标记和清理的速度（导致堆内存无限膨胀），Go 运行时内置了 gcAssistAlloc 机制。 当 P（Processor）检测到当前 Goroutine 分配内存过快，导致全局 GC 进度跟不上时，会强行让当前正在分配内存的 Goroutine 停下手中的业务逻辑，强制去给 GC 帮忙（做标记工作）。 这就像你疯狂往地上扔垃圾，保洁阿姨扫不过来了，直接按住你，让你必须帮她扫完 10 平方米才能继续往前走。

    体现在监控上就是：你的微服务 CPU 飙升（都在做编译和 GC 标记），但业务响应极度缓慢（被强制抓壮丁做 GC Assist），最终导致上游调用方超时断开，流量堆积，彻底雪崩。

    修复与防御性改造

    修改代码极其简单，属于典型的“一行代码优化 60% 性能”的低级 Bug。将正则编译提升到包级别的全局变量或 init() 函数中：

    // 提前预编译，重用状态机
var usernameRegex = regexp.MustCompile(`^[a-zA-Z0-9_]{5,20}$`)

func UserInfoHandler(w http.ResponseWriter, r *http.Request) {
    if !usernameRegex.MatchString(r.FormValue("username")) {
        // ...
    }
}

    重新发布后，Load Average 瞬间跌回 2.x，P99 延迟稳定在 10ms 以内，被标记的 runtime.gcAssistAlloc 耗时在火焰图中彻底消失。

    运维与架构建议

    不要期望通过盲目扩容来解决基础的代码设计缺陷，低效的代码只会将更多的服务器资源转化为无意义的废热。 在常态化的高并发架构中，必须建立持续性能剖析（Continuous Profiling）机制。像 Parca 或 Pyroscope 这样的工具，能够 24 小时不间断采集微服务的 CPU、内存分配火焰图，并将它们与发布版本关联。当某个版本的 P99 出现抖动时，可以直接 Diff 前后版本的火焰图，哪些函数多出了不可理喻的开销，一眼便知。

    同类问题排查清单（FlameGraph & Profiling）

    1. 宿主机高 CPU 快速定界 使用 perf top 观察内核态开销。如果 _raw_spin_lock 和缺页异常类函数（clear_page_erms）排名靠前，高度怀疑应用层存在频繁的小对象内存分配或锁争用。

    2. Go 应用 CPU 火焰图关键特征 当观察到火焰图大量耗时集中在 runtime.mallocgc 时，不要盲目去调大 GOGC 环境变量。必须沿着调用栈往下看，找出是谁在疯狂生成临时对象（常见于：循环内正则编译、高频反射序列化如 json.Unmarshal、无效的字符串切片拼接）。

    3. 警惕 gcAssistAlloc 如果在 Pprof 中看到 runtime.gcAssistAlloc 占据了显著比例，说明业务协程的内存分配速率已突破 GC 阈值。此时系统的 P99 延迟必然惨不忍睹，必须立刻遏制热路径上的堆内存逃逸。

    4. 获取 Profiling 文件的防御性操作 在生产环境拉取 profile 会产生短暂的性能损耗（通常 CPU profile 为 5% 左右），应当通过自动化工具（如定时抓取异常实例）完成，同时避免在流量尖峰期执行长周期的 Heap Profile 抓取引发 STW 抖动。

  • 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 线程。