[rabbitmq-discuss] General approaches for tracking unreclaimed memory

[Matthias Radestock]

Garrett,

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?

> As this is Erlang, I'd assume one point of focus is process creation
> and using whatever techniques are used in Erlang -- e.g. tracing, etc.

See the recent thread at
 
http://www.nabble.com/Re%3A-RabbitMQ-crashes-hard-when-it-runs-out-of-memory-td26014566.html

for some further avenues of investigation.

> One thing I see routinely in the rabbit logs that I'd like to cleanup is:
> 
> exception on TCP connection <0.31875.6> from XXX.XXX.XXX.XXX:XXXXX
> connection_closed_abruptly

That is caused by clients disconnecting without following the proper 
AMQP shutdown protocol, e.g. they simply close the socket instead of 
sending a "connection.close" command and waiting for "connection.close_ok".

With correctly implemented client libraries and applications you should 
only see that in the event of an application crash or network problems.

However, there are no ill effects from this. In particular, no resource 
leakage results from abruptly closed connections.


Regards,

Matthias.