Flow Control


This guide covers a back pressure mechanism applied by RabbitMQ nodes to publishing connections in order to avoid runaway memory usage growth. It is necessary because some components in a node can fall behind particularly fast publishers as they have to do significantly more work than publishing clients (e.g. replicate data to N peer nodes or store it on disk).

How Does Flow Control Work

RabbitMQ will reduce the speed of connections which are publishing too quickly for queues to keep up. No configuration is required.

A flow-controlled connection will show a state of flow in rabbitmqctl, management UI and HTTP API responses. This means the connection is experiencing blocking and unblocking several times a second, in order to keep the rate of message ingress at one that the rest of the server (e.g. queues those messages are route to) can handle.

In general, a connection which is in flow control should not see any difference from normal running; the flow state is there to inform the sysadmin that the publishing rate is restricted, but from the client's perspective it should just look like the network bandwidth to the server is lower than it actually is.

Other components than connections can be in the flow state. Channels, queues and other parts of the system can apply flow control that eventually propagates back to publishing connections.

To find out if consumers and prefetch settings can be key limiting factors, take a look at relevant metrics. See Monitoring and Health Checks guide to learn more.

Getting Help and Providing Feedback

If you have questions about the contents of this guide or any other topic related to RabbitMQ, don't hesitate to ask them on the RabbitMQ mailing list.

Help Us Improve the Docs <3

If you'd like to contribute an improvement to the site, its source is available on GitHub. Simply fork the repository and submit a pull request. Thank you!