RabbitMQ Memory Breakdown: Find Top Memory Queues (2026)

RabbitMQ’s memory usage isn’t just a single number; it’s a complex interplay of message bodies, properties, headers, and internal data structures, and understanding where it’s all going is key to preventing out-of-memory errors.

Here’s how we’ll break down where your RabbitMQ nodes are spending their RAM.

First, let’s get a high-level overview of memory usage by channel. The rabbitmqctl tool is your friend here. Run this command on your RabbitMQ node:

sudo rabbitmqctl status

Look for the memory section in the output. It will show you the total memory used by the RabbitMQ process. While this is useful, it doesn’t tell you what is using the memory.

To drill down into queues, we need to query the management plugin’s HTTP API. If you don’t have it enabled, enable it with sudo rabbitmq-plugins enable rabbitmq_management. Then, you can fetch queue statistics. This command lists all queues and their memory usage:

curl -s -u guest:guest http://localhost:15672/api/queues | jq 'sort_by(.memory) | reverse | .[] | select(.memory > 0) | "\(.name) - \(.memory / 1024 / 1024 | floor) MB"'

This curl command hits the management API endpoint for queues, authenticates with the default guest:guest credentials (you should change these!), and then uses jq to process the JSON output. We’re sorting the queues by their memory field in descending order and then displaying the queue name and its memory usage in MB, rounded down. We also filter out queues with zero memory usage.

What you’re seeing here is primarily the memory occupied by message bodies and properties for messages that are currently in memory. RabbitMQ tries to keep messages in RAM for fast delivery. When a queue grows very large, or contains many large messages, its memory footprint increases.

The memory field in the queue stats is a good indicator, but it’s not the whole story. RabbitMQ also has overhead for:

• Message Properties and Headers: Even small messages have associated metadata.
• Internal Data Structures: Indexes, routing tables, and connection information all consume memory.
• Unacknowledged Messages: Messages that have been delivered but not yet acknowledged by consumers still reside in memory.
• Flow Control: If producers are sending messages faster than consumers can process them, RabbitMQ will start holding messages in memory, and this can balloon quickly.

Let’s look at a specific queue to get even more detail. Replace your_queue_name with the actual name of a queue you identified as a memory hog:

curl -s -u guest:guest http://localhost:15672/api/queues/%2f/your_queue_name | jq '.'

This command gives you a detailed JSON object for a single queue. Pay attention to fields like memory, messages_ready, messages_unacknowledged, and consumer_utilisation. messages_ready and messages_unacknowledged give you a clue about the number of messages. The memory field is the raw memory consumption for that queue.

If a particular queue is consuming an inordinate amount of memory, here are the common reasons and how to address them:

1. Large Number of Unacknowledged Messages: Consumers are slow or have crashed.

   • Diagnosis: Check the messages_unacknowledged count for the queue using the single queue API call above. Also, monitor your consumer applications for errors or high latency.
   • Fix: Ensure your consumers are properly acknowledging messages. If consumers are genuinely slow, scale them up or optimize their processing logic. For critical queues, consider implementing dead-lettering to move messages that can’t be processed after a certain number of retries.
   • Why it works: Unacknowledged messages are still held by RabbitMQ, waiting for the consumer’s confirmation. Releasing them (via acknowledgement) frees up memory.

2. Large Message Payloads: Messages themselves are very big.

   • Diagnosis: This is harder to diagnose directly from RabbitMQ’s stats. You’d typically infer this if the message count for a high-memory queue is not exceptionally high, but the memory usage is. Examine your producer logic to see what kind of data is being sent.
   • Fix: Optimize message payloads. Compress data before sending, send only necessary fields, or consider storing large data externally (e.g., S3) and sending a reference/URL in the message.
   • Why it works: Smaller message bodies directly translate to less memory consumed per message.

3. Queue is Growing Too Fast (High Throughput): Producers are overwhelming consumers.

   • Diagnosis: Monitor messages_published and messages_delivered rates, and compare them to messages_redelivered or messages_unacknowledged growth. High rates with a steadily increasing messages_ready count indicate this.
   • Fix: Implement flow control on producers, scale up consumers, or throttle producer rates. RabbitMQ has built-in flow control mechanisms when memory limits are approached, but it’s better to manage throughput proactively.
   • Why it works: By managing the rate at which messages enter the system relative to the rate at which they leave, you prevent the queue from building up indefinitely in memory.

4. Long-Lived Queues with Many Messages: Queues that are not being cleared or have a very high message retention policy.

   • Diagnosis: Check the messages count (total messages in the queue, ready + unacknowledged) and the memory usage. If these are consistently high over time and not decreasing, it indicates a persistent backlog.
   • Fix: Ensure consumers are connected and processing. If messages are no longer needed, consider manually clearing the queue via the management UI or rabbitmqctl purge_queue your_queue_name. For persistent queues, ensure there’s a mechanism to eventually consume or expire messages.
   • Why it works: Clearing out old or unnecessary messages directly reduces the number of items RabbitMQ needs to keep track of and hold in memory.

5. Memory Leaks in Erlang/RabbitMQ: While rare, bugs can cause memory to be allocated and never released.

   • Diagnosis: Observe memory usage over time. If memory usage steadily climbs and never drops, even after periods of low activity, it might indicate a leak. Check RabbitMQ release notes for known issues.
   • Fix: Upgrade to the latest stable RabbitMQ version. If the issue persists, report it to the RabbitMQ community with detailed logs and reproduction steps.
   • Why it works: Software updates often include bug fixes that resolve memory management issues.

6. Too Many Small Queues: Each queue has some overhead. A very large number of queues, even with few messages, can add up.

   • Diagnosis: Check the total number of queues using sudo rabbitmqctl list_queues name. If this number is in the tens or hundreds of thousands, it’s worth investigating.
   • Fix: Consolidate queues where possible. Use topic exchanges or fanout exchanges with routing keys to send messages to multiple consumers from a single queue, rather than creating a queue per consumer or per message type.
   • Why it works: Reducing the number of queue objects reduces the overall memory footprint of RabbitMQ’s internal data structures.

Once you’ve addressed the high memory queues, you might encounter issues with the management plugin’s performance itself if it’s trying to collect stats from an enormous number of queues.