[rabbitmq-discuss] OOM kill

[Matthias Radestock]

On 08/03/14 16:38, Dmitry Andrianov wrote:
> I just know that server process dying completely is a very bad thing
> to happen.

Indeed. but note that in your case the server didn't die off its own 
accord; it was bumped off by the OOM killer.

With ulimits, channel limits and buffer sizes configured carefully, and 
restrictions in place for exchange/binding/queue creation, you can 
certainly prevent rabbit from breaching memory limits.

> So if I was able to extend Rabbit, I would be thinking of adding
> something like a limiting policy to every tcp listener. So for
> internal port (inaccessible from internet) I would not set any limits
> while on the ssl listener (accessible from the internet) I would
> configure a limiting policy either with fixed limit (say 10k
> connections) or memory-based policy (start limiting connections when
> memory is low).

Right. This is achievable with common firewall products.

> Something like that. But from Michael's words I understand that it is
> not something you need yourself or think is needed by the community
> because it is not how Rabbit is supposed to be used.

We are in fact quite keen to improve rabbit to make it more bullet 
proof. We have long-standing bugs open in our tracker for the issues you 
raised. But any solution we come up with must a) cover a broad spectrum 
of use cases, b) not be easily handled by off-the-shelf companion 
products like firewalls.

Regards,

Matthias