企业官网建设流程全解析

Apache RocketMQ 5.x 系统配置指南：JVM 参数与 Linux 内核调优实践

【免费下载链接】rocketmqApache RocketMQ is a cloud native messaging and streaming platform, making it simple to build event-driven applications.项目地址: https://gitcode.com/gh_mirrors/ro/rocketmq

本指南聚焦 Apache RocketMQ 5.x 的系统级配置，涵盖 Broker/NameServer 等核心服务的 JVM 参数选型（堆内存、直接内存、GC 策略与日志）以及 Linux 内核参数调优（内存水位、mmap 映射、文件描述符与 I/O 调度器）。读者将掌握如何参照仓库内 os.sh 与 runbroker.sh 落地一套面向生产环境的基础配置，并理解每条参数背后对应的 RocketMQ 存储与运行机制。

1 JVM 选项（JVM Options）

RocketMQ 的 Broker、NameServer 等 Java 服务对 GC 停顿与内存分配延迟高度敏感。官方推荐使用最新发布的 JDK 1.8 版本，以下配置原则与参数均来自官方系统配置文档，且与仓库内启动脚本 runbroker.sh 的实际默认值一致。

1.1 堆内存：固定 Xms 与 Xmx

将-Xms与-Xmx设置为相同值，可以防止 JVM 在运行期动态调整堆大小，避免由此引入的性能抖动：

-server -Xms8g -Xmx8g -Xmn4g

其中-Xmn4g为新生代预留 4GB。在 runbroker.sh 中，Broker 启动脚本固定使用-server -Xms8g -Xmx8g；而 runserver.sh（NameServer 等服务）则默认使用-server -Xms4g -Xmx4g，说明不同角色应根据负载规模独立设定堆大小。

1.2 直接内存：-XX:MaxDirectMemorySize

RocketMQ 的网络通信与部分 I/O 路径会使用 Direct ByteBuffer。当直接内存使用量增长到指定上限时，会触发 Full GC，因此需要显式设大上限：

-XX:MaxDirectMemorySize=15g

该参数同样出现在 runbroker.sh 中，作为 Broker 的默认配置。

1.3 堆预触达：-XX:+AlwaysPreTouch

如果不在乎 Broker 的启动时间，可以开启堆预触达，让 JVM 在初始化阶段就完成每一页堆内存的物理分配，避免运行时首次访问触发缺页中断：

-XX:+AlwaysPreTouch

runbroker.sh 默认开启该选项，代价是启动阶段耗时略有增加。

1.4 关闭偏向锁

关闭偏向锁可以减少 JVM 停顿：

-XX:-UseBiasedLocking

该选项在 runbroker.sh 中默认启用。

1.5 GC 策略：JDK 1.8 下推荐 G1

官方推荐在 JDK 1.8 上使用 G1 收集器，并给出了经过生产环境验证的参数组合：

-XX:+UseG1GC -XX:G1HeapRegionSize=16m -XX:G1ReservePercent=25 -XX:InitiatingHeapOccupancyPercent=30

• -XX:G1HeapRegionSize=16m：指定 G1 Region 大小；
• -XX:G1ReservePercent=25：为晋升预留 25% 的堆空间，降低 Full GC 概率；
• -XX:InitiatingHeapOccupancyPercent=30：堆占用率达到 30% 即触发并发标记周期。

官方说明这些 GC 选项看起来略显激进，但在生产环境中已被证明能提供良好的性能。从 runbroker.sh 的choose_gc_options逻辑可以看到，脚本会根据运行时 JDK 大版本自动选择：Java 8 以下使用 CMS 组合，Java 9+（JAVA_MAJOR_VERSION >= 9）则统一使用上述 G1 参数，且额外附带-XX:SoftRefLRUPolicyMSPerMB=0（让 SoftReference 尽快回收，缓解内存压力）。

1.6 GC 日志与暂停控制

不要将-XX:MaxGCPauseMillis设置得过小，否则 JVM 会倾向使用较小的新生代，导致频繁 Minor GC。推荐使用滚动 GC 日志文件：

-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=30m

如果磁盘写入 GC 日志会增大 Broker 延迟，可将 GC 日志重定向到内存文件系统（tmpfs）：

-Xloggc:/dev/shm/mq_gc_%p.log123

这一点与仓库启动脚本的工程实践完全吻合：choose_gc_log_directory会优先将 GC 日志目录指向/dev/shm（Linux）或在 macOS 上创建 RAMDisk，日志文件名带%p（进程号）与%t（时间戳）占位符，并配置 5 个文件、每个 30MB 的滚动策略（runbroker.sh）。注意：JDK 9+ 使用统一的-Xlog:gc*:file=...语法替代旧的-Xloggc系列选项，脚本已对此做了版本分支处理。

2 Linux 内核参数（Linux Kernel Parameters）

仓库的bin目录下提供了 os.sh 脚本，其中列出了可用于生产环境的内核参数（官方说明需在应用前做少量修改）。以下是官方文档点名需要重点关注的参数。

2.1 vm.extra_free_kbytes

告诉内核在后台回收（kswapd 触发）阈值与直接回收（由分配进程触发）阈值之间保留额外空闲内存。RocketMQ 使用该参数避免内存分配时出现高延迟。该参数与内核版本相关。

在 os.sh 中，官方给出的参考值为：

sudo sysctl -w vm.extra_free_kbytes=2000000

2.2 vm.min_free_kbytes

若设置低于 1024KB，系统在高负载下可能变得“微妙地损坏”并容易发生死锁：

sudo sysctl -w vm.min_free_kbytes=1000000

2.3 vm.max_map_count

该参数限制进程可拥有的内存映射区域数量。RocketMQ 通过mmap加载CommitLog与ConsumeQueue文件，因此建议调高：

sudo sysctl -w vm.max_map_count=655360

从源码可以印证这一需求：存储模块的 DefaultMappedFile 通过fileChannel.map(MapMode.READ_WRITE, 0, fileSize)将 CommitLog 等文件映射为MappedByteBuffer，Broker 运行期会维护大量文件映射，映射区域上限不足将直接导致mmap失败、Broker 无法正常写入消息。

2.4 vm.swappiness

定义内核交换内存页的激进程度：值越高越激进，越低越少使用 swap。推荐设置为10以避免交换延迟：

sudo sysctl -w vm.swappiness=10

注意：官方文档推荐 10，而仓库内 os.sh 实际写入的是vm.swappiness=1，两者方向一致（都强烈倾向不换出），实际取值可按部署环境微调，以文档建议 10 为基准。

2.5 文件描述符限制

RocketMQ 需要为CommitLog、ConsumeQueue等文件以及网络连接打开大量文件描述符，推荐设置为655350：

echo 'ulimit -n 655350' >> /etc/profile echo '* hard nofile 655350' >> /etc/security/limits.conf

os.sh 在写入 nofile 限制的同时，还将 memlock 的 soft/hard 限制设为 unlimited，并配合-XX:-UseLargePages使用。

2.6 磁盘调度器：deadline

官方推荐deadline I/O 调度器，因为它能为请求提供有保证的延迟：

echo 'deadline' > /sys/block/${DISK}/queue/scheduler

os.sh 会先通过df -k找出磁盘设备名，再写入 deadline 调度器，最后回读/sys/block/$DISK/queue/scheduler验证是否生效。

2.7 os.sh 中的其他生产参数

除官方文档点名的参数外，os.sh 还包含一组与内存脏页、NUMA 回收等相关的配套设置，可一并参考（注意应用前按实际内核与机器规格确认）：

sudo sysctl -w vm.overcommit_memory=1 sudo sysctl -w vm.drop_caches=1 sudo sysctl -w vm.zone_reclaim_mode=0 sudo sysctl -w vm.dirty_background_ratio=50 sudo sysctl -w vm.dirty_ratio=50 sudo sysctl -w vm.dirty_writeback_centisecs=360000 sudo sysctl -w vm.page-cluster=3

脚本末尾还会在$HOME下创建指向/dev/shm的tmpfs软链接（os.sh），与前述“将 GC 日志放到内存文件系统”的策略配套。执行os.sh后脚本会回显各参数当前值，便于核对是否写入成功。请勿在未评估内核版本与机器规格的情况下直接全量套用。

3 参数落地与验证

3.1 如何应用到启动脚本

仓库的 JVM 参数通过启动脚本集中管理：runbroker.sh 与 runserver.sh 均支持JAVA_OPT_EXT环境变量追加自定义参数（如-Xmx、-XX:MaxDirectMemorySize等），无需改动仓库文件即可覆盖默认值。此外 runbroker.sh 在检测到numactl可用时会默认以--interleave=all启动 Java，或将RMQ_NUMA_NODE指定的节点用于--cpunodebind/--membind绑定，配合vm.zone_reclaim_mode=0减少跨 NUMA 节点访问的延迟。

3.2 验证手段

• 内核参数：执行sysctl vm.max_map_count等命令查看生效值；文件描述符限制用ulimit -n确认；
• GC 日志：检查/dev/shm/rmq_srv_gc_%p_%t.log是否按 5×30MB 滚动生成，确认 G1 参数生效且无频繁 Full GC；
• 存储行为：可通过 store 模块的测试（如 MappedFileTest）观察mmap读写路径，配合vm.max_map_count判断是否需要继续调高。

4 小结

RocketMQ 5.x 的系统配置分为两层：JVM 层负责堆/直接内存、GC 策略与日志，Linux 内核层负责内存水位、mmap 映射上限、文件描述符与磁盘 I/O 调度。官方文档给出的推荐值（-Xms8g -Xmx8g、MaxDirectMemorySize=15g、G1 三件套、swappiness=10、nofile=655350、deadline 调度器）均已落地在 runbroker.sh、runserver.sh 与 os.sh 中，可作为生产部署的可靠基线；内核参数存在版本相关性与机器差异性，应用前应结合/proc/sys/vm/*的官方内核文档与自身规格逐项确认。

【免费下载链接】rocketmqApache RocketMQ is a cloud native messaging and streaming platform, making it simple to build event-driven applications.项目地址: https://gitcode.com/gh_mirrors/ro/rocketmq