ActiveMQ Artemis集群$.artemis.internal.sf大消息堆积问题排查

配置错误排查方向 #

• 集群内部转发配置校验
  • 检查broker.xml中集群连接（cluster-connection）相关配置：
    • 确认*max-hops*值是否合理，过大的跳数会导致内部消息重复转发，加剧$.artemis.internal.sf队列堆积
    • 检查是否开启*forward-when-no-consumers*，大消息场景下无消费者时持续转发会直接引发队列阻塞
    • 验证*confirmation-window-size*是否适配大消息尺寸，过小的确认窗口会导致消息投递确认阻塞
  • 核对三个节点的集群配置一致性，避免节点间转发规则不一致引发异常
• 分页与磁盘配额配置检查
  • 节点3因分页耗尽磁盘，检查全局*max-disk-usage*设置，确认是否未限制分页文件的最大占比；同时查看$.artemis.internal.sf队列的*max-size-bytes*和*page-limit*，是否未针对内部转发队列设置合理的内存/磁盘阈值
  • 确认*page-size-bytes*是否小于单条大消息尺寸，若大消息单条超过分页阈值，会直接写入堆内存，加剧OOM风险
• 大消息处理配置验证
  • 检查全局或地址级的*message-size-bytes*设置，若值过小会强制大消息分页，若分页目录权限不足或空间不够会引发异常
  • 确认JVM参数*-XX:MaxDirectMemorySize*是否配置，大消息默认使用直接内存，该参数未设置或过小会间接导致堆内存溢出

软件Bug可能性分析 #

• 内部转发队列逻辑缺陷
  • $.artemis.internal.sf是集群内部消息转发的核心队列，在大消息+高负载场景下，可能存在转发线程阻塞、消息确认死锁问题，且2.27.1到2.28.0版本未修复该问题
  • 日志中“无法找到目标队列”的异常，可能是集群拓扑变更时，内部转发元数据未及时同步，导致消息投递失败后持续堆积
• 阻塞恢复逻辑缺陷
  • 负载停止后无法自动恢复，大概率是地址阻塞状态未在磁盘压力缓解后自动解除，或是分页文件恢复时出现IO阻塞死锁
• 大消息内存管理泄漏
  • 调整堆内存至6GB仍出现OOM，说明存在内存泄漏或大消息引用未及时释放，可能是大消息在转发过程中，直接内存或堆内存的资源未正确回收

验证与排查步骤 #

1. 临时验证操作
   • 执行artemis queue purge --name="$.artemis.internal.sf"清理堆积消息，观察节点2投递是否恢复、节点3磁盘压力是否缓解
   • 临时修改集群连接配置，关闭*forward-when-no-consumers*，测试大消息场景下是否仍出现堆积
2. 配置一致性校验
   • 对比三个节点broker.xml的集群连接、地址设置、分页配置，排除节点间配置不一致问题
   • 执行artemis queue stat --name="$.artemis.internal.sf"查看队列运行时状态，包括消费者数量、消息平均大小、分页状态等
3. Bug复现与确认
   • 在单节点环境模拟大消息+高负载场景，验证是否能复现相同问题，排除集群拓扑影响
   • 梳理官方版本变更日志，确认是否存在同版本的内部转发队列堆积、大消息内存泄漏相关未修复问题

内容的提问来源于stack exchange，提问作者la00