[rabbitmq-discuss] Possible memory leak?

[David King]

>> I have an EC2 node running rabbitmq 1.7.2. Take a look at its memory over the last month <http://i.imgur.com/LMf02.png>. Looks like a possible memory leak?
> In this graph, have you restarted RabbitMQ around Saturday? Or had
> this sharp edge happened without your intervention?

Yes, that's when I last restarted rabbit. We have to take our site down to do so, and that's not desirable.

> It won't hurt if you upgraded to the newest RabbitMQ release - 1.8.0.
> ...and, more importantly, to Erlang/OTP R13B03 - unless you are running that or a more recent Erlang release already.

According to that graph I'm going to have to restart the node soon anyway, so I'll try that, but if it doesn't fix a known leak that's unlikely to help, right? As for Erlang, we're running R13B-4.

> There might be several causes of the behaviour you described. First,
> your specific usage patterns might not play well with garbage
> collection. For example, we force full garbage collection run when the
> queue is unused for more than 10 seconds. If your queue is constantly
> pinged - you're left to Erlang default garbage collection.  That works
> well most of the time, but sometimes it's not optimal.

That's possible, but Erlang's default garbage collector is a stop-the-world (per-process) collector, so it's shouldn't be *that* dependent on load, it just just introduce pauses per-queue (which would actually be fine for our use-case)

> Second thing, currently the broker keeps all currently handled
> messages in memory. If your RabbitMQ instance handle 70K messages,
> they are all stored in RAM. If that's the case, you could consider
> running our experimental code branch, which tries to page out messages
> to disk and save RAM.

Right, that's why I said that we *don't* do that anymore. I thought someone might remember me from before (when we were doing that) and say "well you have this big queue so don't do that", and I wanted to pre-empt that by saying that we don't do it anymore so that I could avoid writing this paragraph right here. So to be clear, we have 13 queues that all sit at 0 backlog basically all of the time. Certainly no queues that grow at the same rate our memory does.