[rabbitmq-discuss] How to handle extremely large queues

[Greg Poirier]

On Monday, February 17, 2014, Matthias Radestock <matthias at rabbitmq.com>
wrote:

> On 17/02/14 08:23, Michael Klishin wrote:
>
>> If you don't run out of RAM and your consumers can keep up even with 1
>> queue, what issues do you have?
>>
>
> From the original post
> <quote>
> In periods of high utilization of the cluster, we are noticing frequent
> partitioning. We have narrowed it down to this particular use case [i.e.
> extremely large queues]
> </quote>
>
> Matthias
>

Precisely.  Sorry for the tangent. I was obsessing over memory all week.

We are seeing multiple clusters both versions 3.2.3 and 3.1.5 partition
regularly. We haven't had these issues until we started seeing queues
larger than 1 million messages.

I realize this is... Not a good use of RabbitMQ but it is somewhat a
necessity.

We have a three node cluster (2 disk 1 ram). I have disabled paging
messages to disk and set vm high memory watermark at around .75. I've
chosen a three node configuration simply so I can use pause minority. I
have also configured an ha policy with mirroring to all nodes and automatic
synchronization.

We have a strong requirement for consistency and partition tolerance. This
seemed to be the best option. We can tolerate a full RabbitMQ outage but
data loss or inconsistency must be avoided.

This configuration seemed the safest but we are still experiencing
partitions and while they are easily healed, this now leads to queue in
availability for long periods of time while the queues sunchronize. If this
were attributable to network outages, I would understand, but the machines
are in adjacent racks with redundant links to top or rack switches.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20140217/ddb228b5/attachment.html>