configuring sendmail for highload incoming mail
NetComrade
'soft' bounces..
As soon as I get somebody to reboot it, i'd like to make sure it
doesn't happen again..
The server doesn't send a lot of email, maybe a couple a day, but does
receive a lot whenever a newsletter goes out.
The server is an e450 w/4cpu's 2Gig Ram.
I think we currently have a setting for MaxDaeemonChildren to 200, but
as I was reading thru the newsgroups it doesn't seem to be effective..
there was a lot of posts suggesting to run sendmail as
sendmail -bd -odq -q5m, but looking at man sendmail I can't exactly
get undestand what -bd and -odq mean..
Any help is appreciated.. thnx
ger...@gtconnect.net
man sendmail in Processing Options eventually says :
DeliveryMode (dx)
Deliver in mode x. Legal modes are:
.
.
q Just queue the message (deliver during queue
run).
Whether this will help you I dont know. How's your disk space? : >
Bo
>as I was reading thru the newsgroups it doesn't seem to be effective..
This will help, but you need to control the connection rate throttle,
and some other performance limiters. On a machine that size, your
likely biggest problem is sendmail starting itself too many times, and
forcing the LA too high. This can be reduced by using the connection
throttle. If you are using sendmail >=8.10.x then you should also
split your mail queue directories out into multiple subdirs (and then
qf,df, & xf subdirs of that), and also change the queue processing
priority to work on file name, and none of the other options.
For all of these options (and configuration info) see ~/doc/op/op.ps
Bo
Aleksandar Milivojevic
> I think we currently have a setting for MaxDaeemonChildren to 200, but
> as I was reading thru the newsgroups it doesn't seem to be effective..
You probably don't want to limit MaxDaemonChildren (or if you do, set
it to something high, 1000 or 2000 or even higher is perfectly OK,
depending on your environment). Instead, use ConnectionRateThrottle.
The only use I see for MaxDaemonChildren is to prevent sendmail to
reach OS limit on number of concurrent processes.
Also, in case of reaching the limit with MaxDaemonChildren, sendmail
will start to refuse new connections (making denial-of-service attack
very very very simple -- all the attacker needs to do is to make 200
idle connections to your mail server, peace of cake). With
ConnectionRateThrottle, when the limit is reached, new connections
will not be refused, they will be serviced with (small) delay. You
don't even need an attacker to have your service down: 200 concurrent
connections from your modem pool (if you are ISP for example) will put
almost no load on your server, but because of limit you set in
sendmail configuration, your mail server will not be able to serve new
clients.
What you want to use is ConnectionRateThrottle, QueueLA and RefuseLA.
If your E450 will be dedicated mail server, something like:
ConnectionRateThrottle = 8
QueueLA = 10
RefuseLA = 20
should be perfectly OK. You may even set QueueLA and RefuseLA much
higher (say 20/50) -- if all services on your server are responsive
and fast, than it is perfectly OK to have high load average on it (in
your case load average of 3 means that one of your 4 processors is
sitting doing nothing at all). If your E450 is not going to be
dedicated mail server and/or if you will use POP3/IMAP service also,
you might want to lower ConnectionRateThrottle to 4. You will
definitively want to experiment with those 3 values and see how the
load on your server behaves when you change them (keep in mind that
mail server that refuses connections is not usable mail server :-)
--
Aleksandar Milivojević <al...@fly.srk.fer.hr>
Opinions expressed herein are my own.
Statements included here may be fiction rather than truth.
Per Hedeland
<al...@fly.srk.fer.hr> writes:
>What you want to use is ConnectionRateThrottle, QueueLA and RefuseLA.
>If your E450 will be dedicated mail server, something like:
>
>ConnectionRateThrottle = 8
>QueueLA = 10
>RefuseLA = 20
>
>should be perfectly OK.
On a dedicated mail server, you want to set QueueLA *higher* than
RefuseLA - the other way around will cause your queue to explode when
the load is high (assuming you reach QueueLA of course), you accept lots
of new messages but can't get rid of them as the load average hovers
around RefuseLA - the many messages in the queue drive up disk I/O and
thereby the load average.
The default of QueueLA lower than RefuseLA only makes sense for a server
that does other things besides mail, where you want to reduce the impact
of the mail load on the other functions by queuing instead of delivering
when the load is high.
--Per Hedeland
p...@bluetail.com