[rabbitmq-discuss] OOM kill
simon at rabbitmq.com
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
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
There shouldn't be, no. But thanks for that information; I will be
investigating this today and it might prove useful.
More information about the rabbitmq-discuss