[rabbitmq-discuss] Excessive RabbitMQ memory consumption

[Matt Pietrek]

Thanks Simone! I figured there was something like this. And the discussion
you referenced is also very helpful.

Matt


On Thu, Nov 21, 2013 at 11:54 AM, Simone Sciarrati <s.sciarrati at gmail.com>wrote:

> 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
> >
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20131121/c93d75da/attachment.htm>