[zeromq-dev] Improving zeromq in OOM conditions

[Paul Colomiets]

On Tue, May 17, 2011 at 11:26 AM, Martin Sustrik <sustrik at 250bpm.com> wrote:
>
> 1. Use finite default HWM.
> 2. Use finite default MAXMSGSIZE.
> 3. Implement a MAXCONNECTIONS option with finite default.
> 4. Think hard about whether it makes sense to allow infinite as an valid
> option for any of the above.
>
Ok, I'd like to configure applications in the following way:
1. I should have up to 10 connections max (which is very small cluser)  in
10 application sockets (we build applications as many interconnected
services)
2. Maximum msg size is 1Mb (which is ok, even for some web pages)
3. HWM should be about 100
Which means I should reserve 10Gb for this application, which under usual
load takes less than 1Gb (most messages are 10Kb). When application is
designed well, and zerogw has no memory-related asserts, I can set ulimit
for application (or run it on 2Gb machine with overcommit turned off), and
be sure that when lots of big messages are sent to the application it will
be a bit slow for some time, but will not crash, dropping hundreds of
messages.


> However, that's my personal opinion. If you still feel like you should
> handle the OOM situation when it hits, feel free to try. However, don't do
> any guesswork. With OOM handling the guesses mostly turn out to be false.
> Make a test instead and fix the problem you'll get.
>

You don't fear, sorry :) I do start with testing, but the aim is to remove
all alloc_assert's anyway.


> Also keep in mind that your sophisticated OOM handling is likely to be
> spoiled by OS OOM killer hitting in and killing the whole process.
>
No. There are usually two cases:

1. overcommit is on: malloc always returns valid pointer, OOM killer stops
applications on memory access
2. overcommit is off: malloc returns NULL on OOM, no applications are killed

There is exception to rule 1, if ulimit is reached malloc returns NULL, but
application is not killed.

Anyway you don't scare me, so let's stop bikeshedding and speak about
implemenation (will start another thread for that shortly).

--
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110517/6855ff6c/attachment.htm>