On Tue, May 17, 2011 at 11:26 AM, Martin Sustrik <[email protected]> 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
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
