The following can be limited in RabbitMQ:
- Max number of queues per vhost
- Max number of connections per vhost/user
- Max number of channels per user
- Max number of channels per connection. (“channel_max”)
- Total max connections (“connections_max”)
- Maximum message size (“max_message_size”)
There is also a frame_max, but that is rarely an issue and won’t be covered in this post. We’ll also cover “default_consumer_prefetch”, which is not strictly a limit but is good to set just in case.
Max number of connections per vhost/user
The maximum number of connections per vhost was introduced in RabbitMQ 3.7.0 and is a very good limit to use. Each connection uses some amount of RAM and CPU, so if you have a leak in connection creation, which is unfortunately common, it will run your server out of resources in a short period of time.
Image 1. Example of setting the max connections for a vhost.
CloudAMQP sponsored the development for max-connections per user. You can read more about that in the blog post: Connection limit per user - a community requested feature made available by Erlang Solutions and CloudAMQP.
Max number of queues per vhost
Similar to the number of connections per vhost/user, you can also limit the number of queues per vhost. Each queue requires a certain number of Erlang processes (more if you use HA), and the Erlang virtual machine must check in on each queue to collect metrics, which becomes resource heavy if you use a lot of queues in an unnecessary way.
Max number of channels per user
Included in the development of the CloudAMQP sponsored development for max connections per user, there is also a possibility to set max channels per user. This is very useful when one or several connections have many channels, it will consume a lot of resources.
Max-number of channels per connection (“channel_max”)
A feature that has been available for a long time is setting the maximum number of channels per connection. If you know that you will only use 1 or 2 channels per connection, you can set this to 2. Occasionally, users open a new channel for each publish or subscribe on a connection and that leads to a channel leak, eventually making the whole node become unavailable.
On our shared servers, we have a default channel_max of 200.
Total max connections (“connections_max”)
Limiting the total number of connections via the parameter “connections_max”.
If you know that you will only ever have, say, 500 connections, you can limit
this to 510 or so, and thereby have some headroom.
Maximum message size (“max_message_size”)
RabbitMQ likes smaller messages (less than 4kB). Bigger messages take longer to process, longer to write to disk and send out to all nodes that need them, and take longer to write to all consumers, etc. The standard advice if you regularly have larger messages is to put them into storage and then send a pointer to that in the message. Large messages not only occupy a lot of RAM and disk, but they can make it hard to start the broker too. If you are not going to send large messages, limit max_message_size to say 1MB.
default_consumer_prefetch
It is also possible to set a default consumer prefetch. A common issue is that a client doesn’t set a prefetch and starts to consume a long queue with hundreds of thousands of messages, and then the consumer crashes, and RabbitMQ has to deliver the messages again. With a default prefetch, it is possible to set this to a value of 1 or 5.
Flawless RabbitMQ instance
Now that you know how useful setting limits in your RabbitMQ instance can be, we hope you’ll take a look at your current settings and firm things up.
We hope these hints, tips, and tricks help you set up a flawless RabbitMQ instance! If you need more support, please get in touch with our friendly team. Did we leave something out? Send us your thoughts and comments via an email to contact@cloudamqp.com
All the best,
/Johan Rhodin and the CloudAMQP team
