Thanks a lot, now I can figure out what consumes the memory when it happens the next time. Hopefully, I will never get the chance again. At that time, the management plugin was unreachable BTW. I recovered from the bad condition by restarting everything. It's a production system.<br><br>I will give 2.7.1 a chance as soon as possible. But if you have any idea what could have triggered this bad behavior I would appreciate a hint.<br><br>Regards, Ingo<br><br>Am Dienstag, 6. März 2012 13:15:41 UTC+1 schrieb Simon MacMullen:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 06/03/12 11:38, ingo schramm wrote:<br>&gt; I do *not* use a mirrored queue :)<p>Ah, right, that's how I read "queues distributed over all nodes".</p><p>Hmm. It's still easier to figure out the memory use of RabbitMQ on <br>2.7.1, but for 2.6.1 you could check per-queue memory use with <br>"rabbitmqctl list_queues name memory" (or look in mgmt). If this doesn't <br>bring anything useful up then:</p><p>* Become the user the broker is running as<br>* Run "erl -sname foo -remsh rabbit@$(hostname -s)" to get a shell into <br>the running broker<br>* Invoke "erlang:memory()." for an overview of memory use in the VM.<br>* Invoke "lists:sublist(lists:reverse(<wbr>lists:sort([{process_info(Pid,<br>memory), Pid, process_info(Pid)} || Pid &lt;- processes()])), 10)." for a <br>lit of the top 10 memory using processes, and some information on each one.</p><p>Cheers, Simon</p><p>-- <br>Simon MacMullen<br>RabbitMQ, VMware<br>______________________________<wbr>_________________<br>rabbitmq-discuss mailing list<br><a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.<wbr>rabbitmq.com</a><br><a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/<wbr>cgi-bin/mailman/listinfo/<wbr>rabbitmq-discuss</a><br></p><p></p><p></p><p></p><p></p></blockquote>