[rabbitmq-discuss] RabbitMQ broker's death by one cut: robustness problem

• Previous message: [rabbitmq-discuss] RabbitMQ broker's death by one cut: robustness problem
• Next message: [rabbitmq-discuss] RabbitMQ broker's death by one cut: robustness problem
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Tony Garnock-Jones wrote:
> Lev Walkin wrote:
>> I've already had two power outages in our triple-redundant industrial
>> grade colocation in San Jose. How do I disable power outages?
> 
> Point taken. My point was that you may wish to reduce avoidable harm.

Speaking of OOM killer, it is not wise to disable OOM on a 
dedicated-to-AMQ system with 16 Gigs of RAM and 4 Gigs of swap.

If AMQP can't cope with about 300k unconfirmed messages on the queue (it 
grows beyond _gigabytes_ when all these unconfirmed messages are "in 
flight" to the destination), you're bound have a hard stop at some point 
anyway.

Better have erlang killed with OOM than box killed because of kernel 
panic, or because sshd is killed (when OOM is disabled just for the beam 
process) and you can never reach your machine again.

-- 
Lev Walkin
vlm at lionet.info

• Previous message: [rabbitmq-discuss] RabbitMQ broker's death by one cut: robustness problem
• Next message: [rabbitmq-discuss] RabbitMQ broker's death by one cut: robustness problem
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]