ActiveMQ Classic使用持久化主题订阅者时性能异常缓慢

为支持WebSocket重连用户获取遗漏消息，我们将ActiveMQ Classic的普通非持久化订阅改为持久化订阅，初期运行正常，已添加ACK帧确认消息接收，所有消息均能正常确认。

我们还配置了offlineDurableSubscriberTimeout、offlineDurableSubscriberTaskSchedule，以及<policyEntry topic=">" expireMessagesPeriod="120000"/>，通过控制台可见已定期清理离线订阅者。

但很快服务器性能持续下降直至近乎停滞，各项操作加载极慢。我们尝试过Docker镜像部署及AWS实例部署，服务器CPU、内存占用低，流量也不高，无指标能解释性能下降原因。

将应用部署到RabbitMQ服务器则运行正常，推测是ActiveMQ Classic未配置到位。请问是否有人遇到过此类问题或熟悉持久化订阅相关配置？

1. 检查持久化存储配置合理性 #

持久化订阅的消息默认存储在KahaDB中，存储层配置不当会引发隐性性能瓶颈：

• 确认KahaDB的archiveDataLogs已开启，避免未归档的数据日志无限累积；
• 调整maxDataFileLength限制单个数据文件大小（例如设置为1024mb），减少磁盘寻址开销；
• 若使用SSD磁盘，可开启enableIndexWriteAsync参数提升索引写入的异步性能。

2. 验证消息过期与积压情况 #

即使配置了expireMessagesPeriod，也可能存在消息未被正确清理的情况：

• 检查发送的消息是否设置了timeToLive属性，无过期时间的消息不会被expireMessagesPeriod逻辑清理；
• 确认policyEntry的全局配置未被更具体的Topic策略覆盖，确保topic=">"的配置对所有Topic生效；
• 通过ActiveMQ控制台查看每个持久化订阅的消息队列长度，排查是否存在大量未消费的积压消息。

3. 优化离线订阅者清理参数 #

offlineDurableSubscriberTimeout和offlineDurableSubscriberTaskSchedule的参数值可能不合理：

• 若offlineDurableSubscriberTaskSchedule设置过短（如小于60秒），后台清理任务会频繁执行，消耗隐性系统资源；
• 确保offlineDurableSubscriberTimeout设置合理，避免大量离线订阅者长期留存，增加服务器元数据维护负担。

4. 调整线程池配置 #

持久化订阅的消息分发、ACK处理依赖线程池，线程资源不足会导致任务排队：

• 调整systemUsage中的threadPool参数，适当增大maxThreads值；
• 检查WebSocket连接器的线程配置，确保transportConnectors下的maxThreads和minThreads适配当前并发连接数。

5. 避免重复创建无效持久化订阅 #

若客户端重连时重复创建新的持久化订阅（如clientID或订阅名称不固定），会导致服务器积累大量无效元数据：

• 确保客户端使用固定的clientID和订阅名称；
• 定期通过控制台或JMX清理服务器上的无效持久化订阅。

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