[rabbitmq-discuss] Determining Cause of Flow-Control Invocation

[Michael Klishin]

On oct 4, 2013, at 6:40 p.m., Richard Raseley <richard at raseley.com> wrote:

> So, my question is - what other things can I look at to determine the cause of the invocation of flow control

There are 3 cases when RabbitMQ will block publishers (until the underlying problem
is resolved):

 * It consumes more RAM than vm_high_memory_watermark
 * Node has less disk space left than the configured minimum limit
 * RabbitMQ process is out of available file descriptors (ulimit -n)

See http://www.rabbitmq.com/memory.html for more details. RabbitMQ log
should have very visible messages when one of the above happens.

In the first two cases the only solution is to increase capacity of your consumers so that they drain
messages and all alarms unblock. Alternatively, if your data
is temporary in nature, you can set TTL on messages [1].

In the latter case (file descriptors) you should configure open file handles limit for
the Rabbit process or use fewer connections.

1. http://www.rabbitmq.com/ttl.html

MK



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20131004/de10e9c4/attachment.pgp>