Binary heap size consumes 6 GB

[vaibhavjoshi888]

Hi Team,

Below is my RabbitMQ Server details
RabbitMQ 3.8.26
Erlang 23.2.7

I have set up RabbitMQ cluster with 3 node we are running quorum ques on this cluster, am facing memory leaking issue RabbitMQ server eating all memory, i have allotted 70% ram to RabbitMQ but its taking entire memory and due to this RabbitMQ node is getting hang and after some time it get down.

I search on google so found root cause binaries taking these much memory you can clearly check in below snapshot

Kindly suggest resolution on this issue or any version upgrade will work for this any resolution will be acceptable

Thanks in advance
Vaibhav Joshi

[michaelklishin]

I will convert this issue to a GitHub discussion. Currently GitHub will automatically close and lock the issue even though your question will be transferred and responded to elsewhere. This is to let you know that we do not intend to ignore this but this is how the current GitHub conversion mechanism makes it seem for the users :(

[michaelklishin]

There is no evidence of a memory leak. It can be natural for binaries to consume a significant percentage of node's memory but on Erlang 23.2.7, and if the leak is building up over time, and you run RabbitMQ on Windows, you may be looking at #3906, #3936.

There is no shortage of scenarios where your own application code can result in an ever increasing binary heap size:

• Connection leaks or high connection churn or a large number of concurrent connections without adequate tuning
• Channel leaks
• Messages building up, in particular messages published as transient

Only monitoring memory distribution and other metrics over time can help narrow the issue down. You haven't posted any code or metrics for us to work with. One management UI screenshot does not cut it. This is open source software you consume for free,
so please help others help you or investigate what's going on on your own.

[michaelklishin]

Forgot to mention that the file descriptor state leak (what #3906 and #3936 work around) were addressed in latest patch releases of Erlang 23.3 and 24.2. I don't see any reason to run 3.8 and no reason to run 3.8 on Erlang 23, although we don't have specific evidence to tell.