how many children

[Jean-Paul Natola <jn...@familycareintl.org>]

Hi all,

I'm seeing a bunch of these in my maillog;

prefork: child states: BBBBBBBBBB
prefork: server reached --max-children setting, consider raising it


This what I currently have set in my  startup script

command_args="-d --min-children=2 --max-children=10 --min-spare=2
--max-spare=3 --max-conn-per-child=100 -r ${pidfile}"

Here is what my resources look like;

last pid:  1051;  load averages: 11.02,  9.65,  5.86           
60 processes:  12 running, 48 sleeping
CPU states: 96.9% user,  0.0% nice,  1.2% system,  1.9% interrupt,  0.0% idle
Mem: 336M Active, 47M Inact, 73M Wired, 60M Buf, 38M Free
Swap: 999M Total, 999M Free


So how many children should I set it too?





Jean-Paul 

Re: how many children

[Matt Kettler <mk...@verizon.net>]

Jean-Paul Natola wrote:
> Hi all,
>
> I'm seeing a bunch of these in my maillog;
>
> prefork: child states: BBBBBBBBBB
> prefork: server reached --max-children setting, consider raising it
>
>
> This what I currently have set in my  startup script
>
> command_args="-d --min-children=2 --max-children=10 --min-spare=2
> --max-spare=3 --max-conn-per-child=100 -r ${pidfile}"
>
> Here is what my resources look like;
>
> last pid:  1051;  load averages: 11.02,  9.65,  5.86           
> 60 processes:  12 running, 48 sleeping
> CPU states: 96.9% user,  0.0% nice,  1.2% system,  1.9% interrupt,  0.0% idle
> Mem: 336M Active, 47M Inact, 73M Wired, 60M Buf, 38M Free
> Swap: 999M Total, 999M Free
>
>
> So how many children should I set it too?
>   
Realistically, you don't have enough ram to raise your --max-children by
much.. you could probably raise it to 11, maybe 12, but any higher and
you'd just start swapping which would slow the server down more, which
is NOT helpful.

You might want to look into some front-end techniques to reduce the
overall spam volume being passed on to SA, which would lighten the load.

Things to consider (but what you do and do not use will depend on how
you want YOUR network to behave):
    SMTP layer use of RBLs to reject mail - effective, but false
positive prone.

    sendmail's "greetpause" feature, or similar. - kills some dumb spambots.

    sendmail's bad recipient throttle feature - kills dictionary attacks.

    greylisting -somewhat effective, but will cause mail slowdowns..
Slowdowns can be mitigated somewhat by greylisting selectively using
milter-greylist, where you can dictate a default action of whitelist and
use ACLs to decide when to greylist. I do a lot of things like greylist
all hosts in sorbs-dul, etc, which mitigates the occasional FPs, but
gets me most of the benefit of the RBL..