[rabbitmq-discuss] General approaches for tracking unreclaimed memory

[Garrett Smith]

(repost to list)

On Mon, Oct 26, 2009 at 5:30 PM, Matthias Radestock <matthias at lshift.net> wrote:
> Garrett Smith wrote:
>>
>> Apart from using rabbitmqctl to check some of the more obvious
>> sources for lost memory (e.g. connections, queues, etc.) are there
>> other techniques for tracking down where the broker might be
>> allocating resources that aren't cleaned up?
>
> The output of the various rabbitmqctl list_* commands is definitely the
> first port of call. Do the "row counts" of these increase? Or do the message
> counts in the queues increase?

Hah, I missed something obvious here. Thanks for reminding me to start
at the beginning :)

So, here's the problem, which everyone reasonably faces: when a
consumer goes away, their queues pile up, which is basically a "leak"
at the application/system level (not with rabbit).

I'm being a little lazy here by not looking into the docs or the AMQP
spec, but is there a way to guard against an eventual crash in this
case (I believe this has manifested itself for me once by running out
of Erlang processes, but memory is certainly an issue as well)?

Having worked with qpid a bit, their broker will respect the
time-to-live/expires info associated with a message. I know, at least
in 1.6, rabbit didn't do that. That would be one solution.

A fallback would be a limit to the number of messages a queue could handle.

Short of that, I can run a daemon to routinely check rabbit for queues
that pile up, but that's a moving part I'd prefer to avoid if
possible.

Garrett