<div dir="ltr">Hi,<div><br></div><div>During our performance testing yesterday we saw some interesting behavior. The setup is:</div><div><br></div><div>RabbitMQ x 3 nodes, clustered, behind a load balancer, running on Linux, Erlang 16B03, Rabbit 3.2.3. RabbitMQ nodes running on VMWare ESX 4.5</div>
<div><br></div><div>What we observed was a run in the morning publishing and consuming a sustained rate of 140K messages/hour across 150 mirrored queues (good).</div><div>The application was shut down, all connections to Rabbit were observed to drop to 0.</div>
<div>An hour or two passes while the team does other things.</div><div>The application was brought back up, connections re-established, and another test run kicked off.</div><div>This time the max sustained rate is about 65K messages/hour (bad). The reason was narrowed down to Rabbit not accepting published messages any faster than that.</div>
<div>Disk I/O was checked - we're on a very fast SAN and there was no issue.</div><div>Load balancer was checked, it's not preventing the issue.</div><div>Finally, the RabbitMQ nodes were stopped and restarted and another test run was made, and suddenly we are back up to 140K messages/hour.</div>
<div>The logs show no memory alarms or flow control messages - in fact the logs are "clean".</div><div><br></div><div>Any suggestions on places to look to see what the underlying issue might be?</div><div><br></div>
<div>In real life I don't expect to start and stop applications, so this may or may not be a concern, but we are very curious about the observed behavior.</div><div><br></div><div>Cheers,</div><div><br></div><div>Ron</div>
</div>