[rabbitmq-discuss] Excessive RabbitMQ memory consumption

[Matt Pietrek]

Thanks Michael and Simon - This is immensely helpful. Just knowing some
place to focus on is great. Given the nature of the issues, it appears
consistent with what we've observed in our various test scenarios.

I've got 3.2.1 running in a different cluster for testing. Hopefully it
will validate quickly and we can move to it sooner rather than later.

One more question - Without restarting the broker, is there any way to
restart just the management agent and/or force a GC so as to clean up
memory? This might buy us some time until we can upgrade.

Thanks again,

Matt


On Thu, Nov 21, 2013 at 4:11 AM, Simon MacMullen <simon at rabbitmq.com> wrote:

> On 21/11/13 02:47, Matt Pietrek wrote:
>
>> The management database at 1.3GB seems excessive.
>>
>
> To add to what Michael said: yes, this is excessive. Almost certainly one
> of the leaks we've fixed since 3.0.2.
>
> As a rule of thumb I would expect the management DB to take about as much
> memory as Mnesia. Certainly within an order of magnitude anyway.
>
> I'm reluctant to get into tracking down exactly which old bug you are
> seeing :-) but there were definitely leaks in 3.0.2 such that:
>
> * Connection and channel data was never cleaned up for nodes that crashed
>
> * Consumer records might not be cleaned up
>
> * Fine stats were issued for queue slaves and never cleaned up even when
> the queue was deleted
>
> If you can't upgrade, in addition to the suggestions Michael made
> (increase the stats interval or disable the management plugin) there's a
> halfway house: disable fine stats collection (
> http://previous.rabbitmq.com/v3_0_x/management.html#fine-stats). This
> will stop you seeing message rates but will prevent some of those leaks.
>
> Cheers, Simon
>
> --
> Simon MacMullen
> RabbitMQ, Pivotal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20131121/e416bbe3/attachment.htm>