ActiveMQ Artemis：无生产者/消费者时磁盘持续占满问题排查求助

1. 无客户端连接时磁盘持续占满的可能原因 #

• 消息日志损坏引发循环修复：从deleting orphaned file日志来看，Broker重启时会尝试清理孤立文件，但损坏的日志结构可能导致Broker反复执行修复逻辑，不断生成无效日志片段，最终耗尽磁盘。
• 分页文件异常残留：分页机制触发后，若分页文件本身损坏，Broker重启时无法正确识别已处理的分页数据，会反复扫描、重建分页索引，持续写入日志文件。
• 内部后台线程异常循环：Broker负责日志压缩、过期消息清理的后台线程，因日志损坏进入异常循环，不断尝试操作却无法完成，持续产生日志或临时文件。
• 未提交事务残留：生产者被阻断时可能存在未提交的事务，Broker重启后尝试恢复这些事务，反复写入事务日志，导致磁盘占用持续上升。

2. 调试此类问题的方法 #

• 实时跟踪Broker日志：用tail -f broker.log持续监控，重点关注journal、paging相关条目，排查是否有重复出现的错误或循环执行的操作（比如反复删除文件、重复写入日志）。
• 定位磁盘写入源：用lsof -p <broker-pid>查看Broker进程打开的文件，确定是journal文件、分页文件还是临时文件在持续写入；定期执行du -sh ./data/*，观察data目录下各子目录的大小变化，锁定膨胀的目录。
• 启用DEBUG级日志：修改logging.properties，将org.apache.activemq.artemis.core.server和org.apache.activemq.artemis.core.journal的日志级别设为DEBUG，重启Broker后获取后台线程的详细执行逻辑，定位异常点。
• 分析Journal文件内容：使用Artemis自带的JournalDumper工具，导出journal文件内容，检查是否存在无效、重复的记录，判断日志结构是否正常。

3. 确认消息日志损坏并恢复的步骤 #

确认损坏 #

• 检查启动日志：若Broker启动时频繁出现deleting orphaned file、corrupted journal file、failed to read record等报错，可直接判定日志损坏。
• 用JournalDumper工具验证：运行工具解析journal目录，若抛出解析异常，或导出内容存在大量乱码、无效记录，即可确认日志损坏。
• 检查文件系统：用fsck命令检查Broker所在磁盘的文件系统是否存在错误，文件系统损坏也可能导致日志文件异常。

恢复操作 #

1. 完整备份数据目录：先将data目录整体备份，避免恢复操作导致数据进一步丢失。
2. 清理损坏文件：停止Broker后，删除data/journal目录下所有文件；若分页文件也损坏，同步删除data/paging目录下对应队列的分页文件。
3. 启动并验证：启动Broker，此时会重建空的journal和分页目录，检查磁盘占用是否稳定。若需要保留部分数据，可尝试从备份的journal文件中筛选有效记录，通过Artemis导入工具恢复（建议先在测试环境验证）。
4. 优化磁盘配置：恢复后调整max-disk-usage至合理值（如80%），启用disk-scan-period定期检查磁盘状态，避免再次触发极端磁盘占用场景。

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