[rabbitmq-discuss] |Spam| Re: Possible memory leak in the management plugin

Wed Jun 19 16:34:14 BST 2013

Also, I have a patched version of the management plugin which fixes the 
leak I found today:

http://www.rabbitmq.com/releases/plugins/v3.1.1/rabbitmq_management-3.1.1-leakfix1.ez

(see http://www.rabbitmq.com/plugins.html#installing-plugins for where 
to put it, it replaces rabbitmq_management-3.1.1.ez)

If you are able to test this version, that would also be great.

Cheers, Simon

On 19/06/13 15:57, Simon MacMullen wrote:
> Thanks.
>
> Could you run
>
> rabbitmqctl eval
> '{_,_,_,[_,_,_,_,[_,_,{_,[{_,S}]}]]}=sys:get_status(global:whereis_name(rabbit_mgmt_db)),T=element(5,S),ets:foldl(fun(E,_)->io:format("~p~n~n",[E])end,[],T).'
>
>
> please? This will dump the entire leaky table to standard output, so you
> would want to redirect it to a file.
>
> If you could also accompany that with "rabbitmqctl report" so I can see
> what actually exists at that time then I can at least see what is leaking.
>
> Cheers, Simon
>
> On 19/06/13 15:30, Travis Mehlinger wrote:
>> Hi Simon,
>>
>> We aren't doing anything like that. Whenever one of our services starts
>> (which are based on Kombu, if that helps), it plucks a connection from
>> its internal pool, creates a channel on that connection, then binds on
>> its request queue, which hangs around until the service stops. The only
>> thing that deviates from this pattern is our monitor, which connects and
>> disconnects fairly rapidly, and uses exclusive queues.
>>
>> That said, it's entirely possible that we have something floating around
>> that I don't know about that fits the behavior you described. I'll keep
>> digging and see what I can turn up. In the meantime, let me know if
>> there's any more information I can collect from Rabbit.
>>
>> Thanks, Travis
>>
>>
>> On Wed, Jun 19, 2013 at 6:13 AM, Simon MacMullen <simon at rabbitmq.com
>> <mailto:simon at rabbitmq.com>> wrote:
>>
>>     On 18/06/13 16:11, Travis Mehlinger wrote:
>>
>>         We declare those queues as exclusive so they're getting
>> cleaned up
>>         automatically.
>>
>>
>>     I have found a plausible candidate for the leak. But it's dependent
>>     on having a long lived channel which declares and deletes lots of
>>     short-lived queues. We keep some information on the deleted queues
>>     until the channel is closed. Could your monitoring tool be doing
>>     that? Obviously it would have to be deleting queues explicitly, not
>>     relying on them being exclusive.
>>
>>     Cheers, Simon
>>
>>
>>     --
>>     Simon MacMullen
>>     RabbitMQ, Pivotal
>>
>>
>
>

-- 
Simon MacMullen
RabbitMQ, Pivotal