<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2014-02-16 22:32 GMT+04:00 Greg Poirier <span dir="ltr"><<a href="mailto:greg.poirier@opower.com" target="_blank">greg.poirier@opower.com</a>></span>:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>In our current configuration, we have a 3-node cluster with 2 disc and 1 ram node with HA mirroring to all nodes in the cluster. In periods of high utilization of the cluster, we are noticing frequent partitioning. We have narrowed it down to this particular use case as none of our other clusters (running on the same physical hardware with the same cluster configuration) experience this kind of partitioning.</div>


<div><br></div><div>Is there some better way that we can configure RabbitMQ to handle this kind of load pattern? I understand this is perhaps not the best way to use RabbitMQ, but it is unavoidable for the time being. Any suggestions would be appreciated.</div>

</blockquote></div><br>Short answer is: give it more RAM.<br><br clear="all"><div>Relevant blog posts:</div><div><br></div><div><a href="http://blog.travis-ci.com/2013-08-08-solving-the-puzzle-of-scalable-log-processing/">http://blog.travis-ci.com/2013-08-08-solving-the-puzzle-of-scalable-log-processing/</a><br>

</div><div><a href="http://www.rabbitmq.com/blog/2014/01/23/preventing-unbounded-buffers-with-rabbitmq/">http://www.rabbitmq.com/blog/2014/01/23/preventing-unbounded-buffers-with-rabbitmq/</a><br></div>-- <br>MK<br><br><a href="http://github.com/michaelklishin" target="_blank">http://github.com/michaelklishin</a><br>

<a href="http://twitter.com/michaelklishin" target="_blank">http://twitter.com/michaelklishin</a><br>
</div></div>