<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 20, 2013 at 12:04 PM, Matthias Radestock <span dir="ltr"><<a href="mailto:matthias@rabbitmq.com" target="_blank">matthias@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Fair enough, though note that your problems were with mirrored queues,<br>
not the persistence mechanisms. Very few bugs have been found in the<br>
persister in the last few years.</blockquote><div><br></div><div>Gotcha. I can't really imagine a situation where you'd actually want single machine persistence (ie persistent queues without HA), but I guess I'm fairly risk averse.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"></div>
The main reason for the disclaimer is the difficulty in explaining when one would want to change that value and what impact doing so might have.<br>
<br>
But if you believe that the default msg_store file size is hurting<br>
performance significantly, then experimenting with different values is<br>
definitely worthwhile. Let us know what you find. Perhaps then we can<br>
give some better guidance to our users than "don't touch this".</blockquote><div><br></div><div>Sounds good. I'll try to generate a synthetic workload on disk based systems and graph the change in rabbitmq delivery performance. Certainly we know that apps like Riak, with its universal append-only datastore, see a much smaller margin of advantage with SSDs over spinning disks compared to what we're seeing with RabbitMQ on our disk vs SSD nodes. However, I understand what its data store is doing a lot better than I understand what RabbitMQ is doing.<br>
<br></div><div>For instance:<br><br></div><div>- Does RabbitMQ have a compaction step like bitcask or innodb, where after writing a certain amount of append-only work, it coalesces this to a more efficient on disk format?<br>
</div><div>- How are deletes handled on queues that don't fully drain? If I increase the message store size to 500 MiB, but the queues they represent are never fully emptied, will they just grow to max queue size and stay there like InnoDB on disk files?<br>
</div><div><br></div><div>Graeme<br><br></div></div></div></div>