[rabbitmq-discuss] OOM kill

Dmitry Andrianov dmitry.andrianov at alertme.com
Sat Mar 8 19:19:43 GMT 2014


I understand.

However only fixed limit policy can be easily implemented by 3rd party firewall. Only Rabbit itself can implement free-memory based policies when it stops accepting connection when memory drops below a threshold. (Well, firewall can of course poll Rabbit status regularly and change its behaviour based on current memory consumption but it does not look very reliable and also introduces a delay so won't be able to react on a sudden spike of connections)

Cheers

> On 8 Mar 2014, at 17:08, Matthias Radestock <matthias at rabbitmq.com> wrote:
> 
>> 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
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
This email is for the use of the intended recipient(s) only.
If you have received this email in error, please notify the sender immediately and then delete it.
If you are not the intended recipient, you must not use, disclose or distribute this email without the
author's prior permission. AlertMe.com Ltd. is not responsible for any personal views expressed
in this message or any attachments that are those of the individual sender.

AlertMe.com Ltd, 30 Station Road, Cambridge, CB1 2RE, UK.
Registered in England, Company number 578 2908, VAT registration number GB 895 9914 42.




More information about the rabbitmq-discuss mailing list