[rabbitmq-discuss] Occasional slow message on a local machine
Brennan Sellner
bsellner at seegrid.com
Thu Sep 6 14:26:57 BST 2012
On 09/06/2012 05:28 AM, Matthias Radestock wrote:
> On 06/09/12 10:21, Tim Watson wrote:
>> On 6 Sep 2012, at 10:16, Matthias Radestock wrote:
>>> Creation/deletion of durable queues/exchanges/bindings *does* touch
>>> the disk. With an fsync to boot.
We may have a winner... It turns out that the exchange is durable,
though the queues being created and bound are not. Our wrapper around
librabbitmq-c is setting all exchanges to durable; I had (mistakenly)
assumed that the queue's durability must match the exchange's. From
re-reading http://www.rabbitmq.com/tutorials/amqp-concepts.html, it
looks like a durable queue may only bind to durable exchanges, but a
non-durable queue is free to bind to durable and non-durable exchanges.
My apologies for leading anyone astray.
So, a new set of questions:
Which of the following causes Rabbit to touch disk (and possibly fsync)?
- Redeclaring an existing durable exchange
- Binding a non-durable queue to a durable exchange
>> amqp_consume
>
> no.
If binding a non-durable queue to a durable exchange causes disk access,
a possible explanation for the slow amqp_consume call is that the
immediately preceding amqp_queue_bind is at fault. Does Rabbit hit the
disk synchronously before sending the bind-ok method, or is it possible
the disk access could affect later calls?
Depending on the answers to the above, a potential explanation for the
observed behavior could be:
amqp_exchange_declare
- Durable, but being redeclared in all of the problem cases
- May cause delayed fsync
amqp_queue_declare # Sometimes slow
- Non-durable
- Sometimes slowed by the fsync from exchange_declare
amqp_queue_bind # Sometimes slow
- Binding non-durable queue to durable exchange
- May cause synchronous or delayed fsync
- If fsync occurs before bind-ok is sent, we attribute the delay
to queue_bind
amqp_basic_consume # Sometimes slow
- If queue_bind's fsync is delayed, we attribute it to basic_consume
We can certainly change the durability of the exchange if it's at fault,
but I'd like to understand the system's behavior first. :-)
Thanks,
-Brennan
More information about the rabbitmq-discuss
mailing list