[rabbitmq-discuss] OOM kill
matthias at rabbitmq.com
Sat Mar 8 17:08:47 GMT 2014
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.
More information about the rabbitmq-discuss