<div dir="ltr">thanks very much MK<div><br></div><div>So it's good to hear that #ready msgs high is not impacting RabbitMQ performance.</div><div><br></div><div>because we encountered an issues like the total messages in rabbit was up to 300K, while some applications have queues of extremely high #ready, but no #unack, while some applications have queues of high #unack, but no #ready.</div>

<div><br></div><div>thats helps me to troubleshoot which application I should look into.</div><div><br></div><div>Thanks.</div><div>Cheers</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 15, 2014 at 3:42 PM, Michael Klishin <span dir="ltr"><<a href="mailto:mklishin@gopivotal.com" target="_blank">mklishin@gopivotal.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="">On 15 April 2014 at 11:37:39, Juno Chan (<a href="mailto:juno@algorithmictradinggroup.com">juno@algorithmictradinggroup.com</a>) wrote:<br>


> > thanks very much. So, for the queues having high values in ready&<br>
> total # of messages(even go up to 300K messages), rabbit MQ performance<br>
> won't get affected?<br>
> only those queues having high values in unacked and total would<br>
> harm the rabbitMQ performance, is that correct?<br>
<br>
</div>Unacknowledged messages are still kept around by RabbitMQ until they are acknowledged<br>
or rejected, so it’s the total number of messages that really  matters.<br>
<div class=""><br>
> BTW, for 2 applications subscribing to the same subscribe channel,<br>
> 2 separate queues are created, if for some reasons, one of them<br>
> has problems and cause the queue stuck (e.g. high # unack messages)<br>
> will another queue being affected?<br>
<br>
</div>A single queue can only use a single CPU core. The number of messages in the longest<br>
matter a lot less compared to how much disk I/O RabbitMQ has to do, either due to<br>
memory pressure or a high rate of messages published as persistent and routed to<br>
durable queues.<br>
<br>
Avoid overloaded queues as much as possible. See also<br>
<br>
<a href="http://www.rabbitmq.com/blog/2014/01/23/preventing-unbounded-buffers-with-rabbitmq/" target="_blank">http://www.rabbitmq.com/blog/2014/01/23/preventing-unbounded-buffers-with-rabbitmq/</a><br>
<a href="http://www.rabbitmq.com/blog/2014/04/10/consumer-bias-in-rabbitmq-3-3/" target="_blank">http://www.rabbitmq.com/blog/2014/04/10/consumer-bias-in-rabbitmq-3-3/</a><br>
<a href="http://www.rabbitmq.com/blog/2014/04/14/finding-bottlenecks-with-rabbitmq-3-3/" target="_blank">http://www.rabbitmq.com/blog/2014/04/14/finding-bottlenecks-with-rabbitmq-3-3/</a><br>
--<br>
MK<br>
<br>
Software Engineer, Pivotal/RabbitMQ<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Juno Chan<div>Algorithmic Trading Group (ATG) Ltd</div><div><a href="http://www.algorithmictradinggroup.com" target="_blank">www.algorithmictradinggroup.com</a></div>

<div><br></div></div>
</div>