[rabbitmq-discuss] Does SSD improve rabbitmq's performance

Wed Nov 20 20:21:33 GMT 2013

On Wed, Nov 20, 2013 at 12:04 PM, Matthias Radestock
<matthias at rabbitmq.com>wrote:

> Fair enough, though note that your problems were with mirrored queues,
> not the persistence mechanisms. Very few bugs have been found in the
> persister in the last few years.

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.

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.
>
> But if you believe that the default msg_store file size is hurting
> performance significantly, then experimenting with different values is
> definitely worthwhile. Let us know what you find. Perhaps then we can
> give some better guidance to our users than "don't touch this".

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.

For instance:

- 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?
- 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?

Graeme
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20131120/a601e344/attachment.htm>