[rabbitmq-discuss] OOM kill

Mon Mar 10 11:00:52 GMT 2014

On 08/03/2014 11:17AM, Dmitry Andrianov wrote:
> When you say Rabbit will gracefully stop accepting connections when
> ulimit is reached, are you talking about some action explicitly done
> by Rabbit itself when it sees limit approaching or is everything done
> by the OS?

It's dome by RabbitMQ explicitly - since FDs are shared across sockets 
and files we don't want to hit the OS FD limit in the middle of a file 
operation, so we stop accepting new connections before that happens.

> If Rabbit does something - doesn't it make sense to do the same when
> memory is running low?

Again, as mentioned, if we did that and memory had filled up with 
messages we might hit a situation where progress is impossible - the 
broker is full of messages but clients can't connect to consume them.

> i will of course follow your advice and play with ulimit but it does
> not feel very reliable - even if I find ulimit value which works in
> that specific test case, it may stop working when message size
> changes.

Well, the memory alarm system is agnostic to how many messages are in 
the broker and what proportion of available memory they use. You just 
need to set your ulimit low enough that you can't cause the memory limit 
to be breached purely with connections.

> Regarding plugin memory - it worth mentioning that we have couple of
> custom plugins including a custom authentication backend. Can these
> be the root cause? Is there anything that needs to be explicitly done
> by the plugin developer to make sure the memory is accounted
> correctly?

There shouldn't be, no. But thanks for that information; I will be 
investigating this today and it might prove useful.

Cheers, Simon

-- 
Simon MacMullen
RabbitMQ, Pivotal