On Monday, February 17, 2014, Matthias Radestock <<a href="mailto:matthias@rabbitmq.com">matthias@rabbitmq.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 17/02/14 08:23, Michael Klishin wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If you don't run out of RAM and your consumers can keep up even with 1<br>
queue, what issues do you have?<br>
</blockquote>
<br>
>From the original post<br>
<quote><br>
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]<br>
</quote><br>
<br>
Matthias<br>
</blockquote><div><br></div><div>Precisely. �Sorry for the tangent. I was obsessing over memory all week. �</div><div><br></div><div>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.�</div>
<div><br></div><div>I realize this is... Not a good use of RabbitMQ but it is somewhat a necessity.�</div><div><br></div><div>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.�</div>
<div><br></div><div>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.�</div><div>
<br></div><div>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.<span></span></div>