<div dir="ltr">A follow-up with version info that I forgot:<div><ul><li><span style="line-height: normal;">RabbitMQ 3.1.5</span></li><li><span style="line-height: normal;">Erlang R14B04</span><br></li><li><span style="line-height: normal;">.NET client 3.0.2</span></li></ul><div>Also, I meant average message size is less than 1kB, not 1MB.</div><br>On Saturday, August 31, 2013 6:30:24 PM UTC-5, Tyson Stewart wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir="ltr">Hello everyone!<div><br></div><div>We've been experiencing some behavior that I don't understand, and none of my searching or documentation-reading has been fruitful, so I'm here to ask you all for expert knowledge.</div><div><br></div><div>Broadly, we're seeing a lower delivery rate than publish rate. I've attached an image to this message that shows how we're able to keep up when the publish rate is less than 600 messages/second, but above that, consumption falls behind publication. Around 16:00 on that chart, we doubled the number of consumers, and it made no difference that we could tell. The erratic behavior of the publish rate is us turning off publishes of the most active queue because we were falling far enough behind that we became worried. When the backlog would get low enough, we would turn it back on, and we did that a few times.</div><div><br></div><div>Here are some vitals to our cluster:</div><div><ul><li><span style="line-height:normal">2 nodes</span></li><li><span style="line-height:normal">Each node is a m1.xlarge instance hosted in EC2</span></li><li><span style="line-height:normal">We have 133 queues in the cluster (see note below)</span></li><li><span style="line-height:normal">All queues are mirrored (they all use a policy that makes them highly available)</span></li><li><span style="line-height:normal">All queues are durable; we use AWS provisioned IOPS to guarantee enough throughput</span></li><li><span style="line-height:normal">We only use the direct exchange</span></li></ul><div>Regarding the number of queues, there are four kinds: the "main" queues, retry-a queues, retry-b queues, and poison queues. Messages that fail for whatever reason during consumption will get put into the retry queues, and if they fail long enough, they'll wind up in the poison queue where they will stay until we do something with them manually much later. The main queues then see the majority of activity.</div></div><div><br></div><div>The average message size is less than 1MB. At nearly one million messages, we were still under 1GB of memory usage, and our high watermark is 5.9GB.&nbsp;</div><div><br></div><div>Disk IOPS don't appear to be the problem. Metrics indicated we still had plenty of headroom. Furthermore, if IOPS were the limitation, I would have expected the delivery rate to increase as the publish rate decreased while the consumers worked through the queue. It did not, however, as shown on the chart.</div><div><br></div><div>My question primarily is: <b>What do you think is limiting our consumption rate?</b>&nbsp;I'm curious about what affects consumption rate in general, though. Any advice would be appreciated at this point. Questions for clarification are also welcome!</div></div></blockquote></div></div>