当 RocketMQ 使用过程中出现 资源耗尽（如内存不足、线程阻塞、文件句柄耗尽、网络连接过多等），这通常意味着当前配置无法支撑当前的消息吞吐量或客户端负载。是否需要调整 RocketMQ 的参数，答案是：是的，通常需要根据具体资源瓶颈进行调优。

---

🔍 一、常见“资源耗尽”问题及表现

资源类型	典型现象	可能原因
JVM 内存耗尽	OutOfMemoryError、频繁 Full GC、Broker 或 Producer/Consumer 崩溃	消息堆积、消息体过大、消费者慢、JVM 参数不合理
线程池耗尽	消息发送/消费延迟高、线程池拒绝任务	消费者并发不足、线程池配置小
文件句柄耗尽（too many open files）	Broker 启动失败、网络连接异常	Linux 系统限制、连接数过多
网络连接耗尽	无法连接 NameServer/Broker	客户端实例过多、未正确关闭
磁盘空间耗尽	Broker 停止写入、日志报错	消息堆积未清理、日志保留策略不合理
CPU 耗尽	系统卡顿、响应慢	消息量过大、GC 频繁、刷盘策略太重

---

🛠️ 二、需要调整的 RocketMQ 参数（分 Broker、Producer、Consumer）

✅ 1. Broker 端调优（broker.conf）

参数	说明	建议调整
brokerRole	主从角色：ASYNC_MASTER / SYNC_MASTER / SLAVE	生产环境建议 SYNC_MASTER + SLAVE 提高可靠性
flushDiskType	刷盘方式：ASYNC_FLUSH（异步） / SYNC_FLUSH（同步）	高吞吐用 ASYNC_FLUSH，高可靠用 SYNC_FLUSH
mapedFileSizeCommitLog	单个 CommitLog 文件大小（默认 1G）	可保持默认
mappedFileSizeConsumeQueue	ConsumeQueue 文件大小	保持默认
deleteWhen 和 fileReservedTime	删除文件时间（如 04 表示凌晨4点删），保留时间（单位小时）	建议 fileReservedTime=48（保留2天）
maxTransferBytesOnMessageInMemory	内存中单次传输最大字节数	调大可提升吞吐
maxTransferCountOnMessageInMemory	内存中单次传输最大消息数	调大
listenPort	Broker 监听端口	确保不冲突
enableCalcFilterBitMap	是否启用布隆过滤	消费过滤多时可开启

⚠️ 重点：如果磁盘写入压力大，优先调整 flushDiskType=ASYNC_FLUSH 并确保磁盘性能足够。

---

✅ 2. Producer 端调优

参数	说明	建议
sendMsgTimeout	发送超时时间（默认 3000ms）	网络差可调大（如 10000）
retryTimesWhenSendFailed	同步发送失败重试次数	建议 2~3 次
maxMessageSize	最大消息大小（默认 4MB）	最大可设 1024 * 1024 * 4 = 4MB
compressMsgBodyOverHowmuch	超过多少字节压缩消息	如 1024 * 4（4KB）以上压缩
defaultTopicQueueNums	默认队列数	可调大（如 8~16）提高并发

---

✅ 3. Consumer 端调优

参数	说明	建议
consumeMessageBatchMaxSize	每次消费最大消息数（默认 1）	批量消费可调大（如 10~32）
pullBatchSize	每次拉取消息数（默认 32）	可调大（如 64）减少网络请求
consumeThreadMin / consumeThreadMax	消费线程数	根据 CPU 和消费速度调整（如 20~100）
brokerSuspendMaxTimeMillis	Broker 挂起最长时间	保持默认
subscription	订阅表达式	避免频繁重新订阅

---

🐧 三、操作系统层调优（必须配合）

RocketMQ 是 Java 应用，但底层依赖 OS 资源。

1. 文件句柄限制（Linux）

# 查看当前限制
ulimit -n

# 临时修改
ulimit -n 65535

# 永久修改：编辑 /etc/security/limits.conf
* soft nofile 65535
* hard nofile 65535

2. JVM 参数（启动脚本 runbroker.sh / runserver.sh）

# 示例：调整 Broker JVM 参数
JAVA_OPT="${JAVA_OPT} -server -Xms8g -Xmx8g -Xmn4g"
JAVA_OPT="${JAVA_OPT} -XX:+UseG1GC -XX:G1HeapRegionSize=16m"
JAVA_OPT="${JAVA_OPT} -XX:MaxGCPauseMillis=25"
JAVA_OPT="${JAVA_OPT} -XX:InitiatingHeapOccupancyPercent=30"

建议：使用 G1 GC，避免 Full GC 停顿。

---

🧪 四、诊断与监控

1. 查看日志

• logs/rocketmqlogs/broker.log
• logs/rocketmqlogs/namesrv.log
• logs/rocketmqlogs/producer.log / consumer.log

搜索关键词：ERROR, WARN, OutOfMemory, RejectedExecution, too many open files

2. 使用 mqadmin 工具

sh mqadmin brokerStatus -n localhost:9876 -b broker-ip:port

查看：commitLog 大小、consumerQueue、runtime 等。

3. 监控指标

• 消息发送/消费 TPS
• 消息堆积量（consumerProgress）
• JVM 内存、GC 次数
• 磁盘 IO、CPU 使用率

---

✅ 五、优化建议总结

场景	建议
内存不足	调大 JVM 堆、使用 G1 GC、减少消息体大小
磁盘写入慢	使用 SSD、flushDiskType=ASYNC_FLUSH、调整刷盘线程
消费慢	增加 consumeThreadMax、批量消费、优化消费逻辑
连接过多	复用 Producer/Consumer 实例、合理关闭
消息堆积	增加消费者实例、提高消费并发、排查消费逻辑瓶颈
频繁 GC	使用 G1、减少对象创建、避免大消息

---

🚫 六、不要做的

• ❌ 不要随意调大 maxMessageSize 到 100MB 以上（影响性能）
• ❌ 不要让 Producer/Consumer 频繁创建销毁
• ❌ 不要忽略操作系统限制（如 ulimit）

---

✅ 七、总结

问题	是否要调参数？	如何调？
资源耗尽	✅ 必须调	结合 JVM、OS、RocketMQ 配置综合优化
内存不够	✅ 调 JVM 和 GC	增大堆、用 G1
磁盘满	✅ 调 fileReservedTime	定期清理、增加磁盘
消费慢	✅ 调消费线程和批量	提高并发
连接多	✅ 调客户端复用	避免频繁创建

✅ 最佳实践：先监控 → 定位瓶颈 → 针对性调参 → 压测验证。