ActiveMQ Artemis进入分页模式后性能下降及磁盘占用过高问题咨询

API 探路者

2026-9-30

问题现象

我所使用的ActiveMQ Artemis 2.7.0部署在Linux Astra环境中，硬件配置为4核CPU、24GB内存、50GB SSD。当broker切换到分页模式后，出现了两类异常：

部分消息处理耗时大幅增加，波动范围为10ms~1800ms
磁盘占用量过高，对应监控如下：

目前该问题仅能通过重启broker临时解决。

现有broker.xml配置

<configuration>
   <core xmlns="urn:activemq:core" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="urn:activemq:core ">
      
      <thread-pool-max-size>50</thread-pool-max-size>
      <name>0.0.0.0</name>


      <persistence-enabled>true</persistence-enabled>

      <journal-type>ASYNCIO</journal-type>

      <paging-directory>data/paging</paging-directory>

      <bindings-directory>data/bindings</bindings-directory>

      <journal-directory>data/journal</journal-directory>

      <large-messages-directory>data/large-messages</large-messages-directory>

      <journal-datasync>true</journal-datasync>

      <journal-min-files>2</journal-min-files>

      <journal-pool-files>10</journal-pool-files>

      <journal-file-size>10M</journal-file-size>

      <journal-buffer-timeout>16000</journal-buffer-timeout>

      <journal-max-io>4096</journal-max-io>
      
      <disk-scan-period>5000</disk-scan-period>

      <max-disk-usage>90</max-disk-usage>

      <critical-analyzer>true</critical-analyzer>

      <critical-analyzer-timeout>120000</critical-analyzer-timeout>

      <critical-analyzer-check-period>60000</critical-analyzer-check-period>

      <critical-analyzer-policy>HALT</critical-analyzer-policy>


      <acceptors>

         <acceptor name="artemis">tcp://0.0.0.0:61616?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=CORE,AMQP;useEpoll=true;</acceptor>

         <acceptor name="amqp">tcp://0.0.0.0:5672?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=AMQP;useEpoll=true;amqpCredits=1000;amqpLowCredits=300</acceptor>

      </acceptors>
   </core>
</configuration>

问题产生原因

版本遗留bug：ActiveMQ Artemis 2.7.0属于较老版本，存在多处分页相关的已知缺陷，包括分页文件使用后未正确回收、分页内存泄漏等，残留的分页文件会持续占用磁盘空间，同时分页模式下需要从磁盘读写消息，随机IO开销激增直接导致消息处理耗时大幅波动。重启broker会临时清理所有未使用的分页文件，释放磁盘和内存资源，因此问题会暂时缓解，流量回升后会再次触发。
配置合理性不足：现有配置未指定地址维度的内存上限和分页阈值，默认内存分配规则不合理，会提前触发分页；journal-buffer-timeout设置为16000ns（即16ms），分页模式下频繁的磁盘刷写会放大该延迟，进一步拉长消息处理耗时。
磁盘阈值设置过高：max-disk-usage设置为90%，SSD在剩余空间低于30%时随机读写性能会出现断崖式下跌，磁盘接近满负荷时IO能力不足直接导致消息处理耗时激增。
缺少分页限流机制：未配置分页满后的限流策略，分页模式下仍持续接收消息，导致分页文件不断膨胀，磁盘IO被打满，陷入性能持续恶化的恶性循环。

优化解决手段

版本升级：优先将ActiveMQ Artemis升级到最新稳定长支持版本（如2.31.x分支），官方已修复所有已知的分页相关缺陷，这是解决该问题的最根本方案。
分页相关配置调整：
- 在core配置下添加地址全局内存限制：<max-size-bytes>10G</max-size-bytes>，同时设置分页大小<page-size-bytes>10M</page-size-bytes>，避免单次分页IO开销过大。
- 添加分页上限和限流策略：<page-limit-bytes>20G</page-limit-bytes>、<page-full-policy>BLOCK</page-full-policy>，分页占用达到上限后阻止新消息写入，避免磁盘被打满。
- 调整journal-buffer-timeout为1000000ns（即1ms），平衡刷写效率和延迟。
磁盘相关配置优化：
- 将max-disk-usage调低到70%，预留足够的磁盘空间保证SSD的读写性能。
- 条件允许的情况下，将journal目录、分页目录分别挂载到独立的SSD盘上，避免journal顺序写和分页随机写抢占IO资源。
运行时优化：
- 配置消息过期时间和死信队列，及时清理无效堆积消息，降低分页触发概率。
- 增加分页文件数量、分页内存占用的监控指标，提前告警避免触发分页模式。

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