[rabbitmq-discuss] General approaches for tracking unreclaimed memory
matthias at lshift.net
Mon Oct 26 22:30:59 GMT 2009
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
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
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.
More information about the rabbitmq-discuss