[rabbitmq-discuss] |Spam| Re: Possible memory leak in the management plugin
simon at rabbitmq.com
Wed Jun 19 15:57:45 BST 2013
Could you run
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.
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
> 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
More information about the rabbitmq-discuss