<div dir="ltr">Michael and Simon,<div><br></div><div>Thank you for taking the time to respond to my question. Yes, I was talking about the per-connection flow-control.<br><br>The thing that stands out to me is Simon's statement that each queue can only use 100% of one core. Looking back at our logging, it does seem that one core was getting close to 100% during this time period (I need to get more granular data to be sure if it hit it or not) - so this would explain what we were seeing.</div>
<div><br></div><div>If that is the case, the obvious solution is to separate the load across multiple queues. I will have to think on that a while, as our current configuration was 1:1 mapping of queue to error type. Some questions:<br>
<br>(*) When a RabbitMQ broker has multiple queues, will it automatically disperse them across the available cores? For example if I have 8 queues on a broker with 8 cores, will it automatically ensure a 1:1 mapping of queues:cores?</div>
<div><br>(*) In the situation where I have been using one queue that mapped well to a logical construct (e.g 1 queue for info, 1 queue for warning, 1 queue for errors) can you share your own personal opinions on the best way to divide that up to ensure distribution across all cores (e.g. one queue per type per core, one queue per producer per type, etc.)?<br>
<br></div><div>I have a little more digging to do.</div><div><br></div><div>Regards,</div><div><br></div><div>Richard</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Oct 4, 2013 at 8:00 AM, Simon MacMullen <span dir="ltr"><<a href="mailto:simon@rabbitmq.com" target="_blank">simon@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 04/10/2013 3:54PM, Michael Klishin wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>So, my question is - what other things can I look at to determine the cause of the invocation of flow control<br>
</blockquote>
There are 3 cases when RabbitMQ will block publishers (until the underlying problem<br>
is resolved):<br>
<br>
� * It consumes more RAM than vm_high_memory_watermark<br>
� * Node has less disk space left than the configured minimum limit<br>
� * RabbitMQ process is out of available file descriptors (ulimit -n)<br>
</blockquote>
<br></div>
I think the OP was talking about this:<br>
<br>
<a href="http://www.rabbitmq.com/memory.html#per-connection" target="_blank">http://www.rabbitmq.com/<u></u>memory.html#per-connection</a><br>
<br>
not this:<br>
<br>
<a href="http://www.rabbitmq.com/memory.html#memsup" target="_blank">http://www.rabbitmq.com/<u></u>memory.html#memsup</a><br>
<br>
I think so, anyway.<div class="HOEnZb"><div class="h5"><br>
<br>
Cheers, Simon<br>
<br>
-- <br>
Simon MacMullen<br>
RabbitMQ, Pivotal<br>
</div></div></blockquote></div><br></div>