ActiveMq,未消费的消息总是在broker的内存中?
我正在使用 ActiveMQ,并且有一个问题:在等待消费者时,持久化消息如何以及何时真正交换到磁盘?
我正在使用虚拟主题,并创建队列消费者来接收来自它们的消息。所有消息都是持久化(我已经验证所有未消费消息的记录确实存在于持久性存储中)
我有多个定期上线和离线的消费者。将jconsole连接到activemq后,我注意到所有未使用的消息似乎都包含在代理的内存中。它们不会交换到磁盘,至少我无法验证这一点。 设置memoryUsage
或打开ProducerFlowControl
- 没有任何效果。如果在流量控制打开的情况下达到内存使用限制,代理是否会被阻止,或者如果流量控制关闭,则内存百分比使用持续增加。
activemq 何时通过将消息存储到磁盘/持久性存储来释放内存?或者确实如此?当队列中有数百万条未消耗(待处理)消息时,如何验证磁盘空间而不是 RAM 会长期限制代理?
I am using ActiveMQ and have a question about how and when the persisted messages do really get swapped to disk, while waiting for consumer?
I am using virtual topics, and create queue consumers to receive messages from them. All messages are persisted (I've verified that records for all non consumed messages do present in the persistence storage)
I have a multiple consumers which regularly come on and off line. Having connected jconsole to activemq I noticed that ALL not consumed messages seem to be contained in broker's memory. They do not get swapped to disk, at least I was not able to verify that.
Setting the memoryUsage
or turning producerFlowControl
on - does not have any effect. Broker is whether blocked if memoryUsage limit is hit with flow control on, or MemoryPercentUsage keeps increasing if flow control is off.
When exactly activemq frees memory by storing the messages to disk/persistence storage? Or does it so? How can I verify it is disk space not RAM which will limit the broker in a long run when there are millions of not consumed (pending) messages in queues?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
请在打开内存使用情况下重新检查,您可以指定消息应持续存在的不同限制。在下面的示例中,当 64 MB 内存已满时,它将开始写入磁盘,最多可达 100 GB。
Please recheck with memoryUsage on, you can specify different limits at which message should persist.In the below example, when 64 mb of memory is full, it starts writing on to disk upto 100 gb.
尝试使用storeCursor并在destinationPolicy中设置内存限制,这将对每个队列从磁盘拉入的内存/消息量实施限制...
try using the storeCursor and setting the memory limit in the destinationPolicy, this will enforce a per queue limit to the amount of memory/messages it will pull in from disk...