ActiveMQ Artemis 持久化存储问题及磁盘耗尽异常问询

一、持久化基础疑问 #

1. 数据写入journal files的时机 #

当消息被标记为持久化时，会在这些阶段写入journal：

• 生产者发送持久化消息后，broker在给生产者发送确认前，会先把消息写入journal（同步/异步刷盘由配置决定，默认异步）；
• 消息被消费后，broker不会立刻删除journal里的记录，而是在事务提交（事务消费场景）或签收确认后，记录删除标记，后续通过journal的清理机制（比如checkpoint、compact）回收空间。

2. 存储占用的影响因素 #

不止是消息数量，这些因素都会影响存储大小：

• 消息本身的总大小：包括消息体、属性、headers的全部内容；
• journal元数据：事务记录、状态标记等额外数据也会占空间；
• 消息状态：未消费的消息会一直占用journal空间，已消费但还没被清理的记录也会暂用空间；
• 配置参数：比如journal文件预分配大小（默认每个100MB）、自动清理开关、max-disk-usage阈值等；
• 分页机制：内存不足时消息会被分页到磁盘，分页文件会占用额外存储。

二、存储耗尽异常分析 #

你遇到的60K条消息就耗完500GB存储、之前200K条反而正常的情况肯定不是正常行为，核心原因大概是这几点：

1. journal空间没有效回收：出队率为0时，消息一直没被消费，journal的清理机制（比如compact）没法回收空间；之前出队率6TPS时，已消费消息的记录会被逐步清理，journal空间能循环利用。要是journal的清理配置（比如journal-compact-min-files、journal-compact-percentage）不合理，已消费的记录也会长期占着空间。
2. 分页文件堆积：日志里显示Starting paging on address，说明broker开了分页。分页文件是额外的磁盘存储，内存装不下消息时就会写到分页文件里。如果分页配置（比如page-size-bytes、max-size-bytes）不对，或者消息没被消费导致分页文件没法删除，就会大量占空间。
3. 共享存储容量计算偏差：日志显示总存储是536.9GB，但你实际分配的是500GB，可能共享存储的容量统计有问题，或者有其他进程在抢用存储。
4. 消息实际大小超预期：虽说平均是2-5KB，但可能存在不少大消息（比如100KB甚至MB级），总存储占用就会远超预估。

日志说明 #

• AMQ222210警告：磁盘使用率到了90%（超过max-disk-usage默认值），broker阻塞生产者是保护机制，防止磁盘彻底耗尽导致服务崩掉；
• AMQ222038警告：地址开启分页，说明内存里的消息到了阈值，开始往分页文件写，这会进一步占磁盘空间。

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