[rabbitmq-discuss] Determining Cause of Flow-Control Invocation

[Richard Raseley]

Michael and Simon,

Thank you for taking the time to respond to my question. Yes, I was talking
about the per-connection flow-control.

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.

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:

(*) 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?

(*) 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.)?

I have a little more digging to do.

Regards,

Richard



On Fri, Oct 4, 2013 at 8:00 AM, Simon MacMullen <simon at rabbitmq.com> wrote:

> On 04/10/2013 3:54PM, Michael Klishin wrote:
>
>> >So, my question is - what other things can I look at to determine the
>>> cause of the invocation of flow control
>>>
>> There are 3 cases when RabbitMQ will block publishers (until the
>> underlying problem
>> is resolved):
>>
>>   * It consumes more RAM than vm_high_memory_watermark
>>   * Node has less disk space left than the configured minimum limit
>>   * RabbitMQ process is out of available file descriptors (ulimit -n)
>>
>
> I think the OP was talking about this:
>
> http://www.rabbitmq.com/**memory.html#per-connection<http://www.rabbitmq.com/memory.html#per-connection>
>
> not this:
>
> http://www.rabbitmq.com/**memory.html#memsup<http://www.rabbitmq.com/memory.html#memsup>
>
> I think so, anyway.
>
>
> Cheers, Simon
>
> --
> Simon MacMullen
> RabbitMQ, Pivotal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20131004/02dfa02b/attachment.htm>