[rabbitmq-discuss] Excessive RabbitMQ memory consumption

Thu Nov 21 19:54:39 GMT 2013

Hi,

As reported in this message
http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2012-April/019446.html
you should be able to do:

rabbitmqctl eval 'application:stop(rabbitmq_management).'
rabbitmqctl eval 'application:start(rabbitmq_management).'

to just restart the management plugin. I have had the same issue and
stopping/starting the management app dropped the memory usage, in my
case it took 2/3 minutes to complete the command but the node remained
functional during the operation (if I remember correctly we had a
similar amount of memory held by the management db).

Test before you run :)

Simone

On Thu, Nov 21, 2013 at 8:24 PM, Matt Pietrek <mpietrek at skytap.com> wrote:
> 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
>
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>