[Mimedefang] performance tuning once again
David F. Skoll
dfs at roaringpenguin.com
Sun Oct 16 10:40:59 EDT 2005
tomvo at absi.be wrote:
> if the output of "md-mx-ctrl histo " command on the busiest time of the
> day shows that let's half of the slaves have 0 messages scanned, does this
> mean that i can safely lower (MX_MAXIMUM parameter)
Yes, probably. But there's almost no benefit to lowering MX_MAXIMUM.
You should set MX_MAXIMUM so that if it's ever reached, your machine does
not swap. If fewer than MX_MAXIMUM slaves are required, the multiplexor
won't start them. (It only keeps MX_MINIMUM slaves around at all times.)
> I have implemented the following 'performance improving' features:
> - /var/spool/MIMEDefang on a ram disk
> - MX_EMBED_PERL=yes
> - spamassassin only checks message of <100K
Those are all good.
> I am also using the multiplexor queuing using these parameters:
> # Multiplexor queue size -- default is 0 (no queueing)
That's probably way too high. If most of the time, you have fewer than
MX_MAXIMUM slaves, nothing will get queued anyway.
> My main concern is that every know and then,i get these dreaded 'timeout
> before data read' errors (timeout of 10 minutes specified in sendmail.cf)
That's weird. It shouldn't be happening.
> # Number of seconds a process is allowed to scan an email before it is
> # considered dead. The default is 30 seconds; we suggest 600.
> What happens if this limit is exceeded ?
The multiplexor kills the slave and returns "please try again".
> I would like to configure my mail relay in such a way that,
> when for some reason, the mail couldn't be scanned in time, the mail is
> accepted anyway (because we have user's dropping mail directly to the mail
> relay from their mail client's, and if they receive such a 'please try
> again later' error, they get annoyed.
It's a bad idea to have mail clients connect directly to a machine running
MIMEDefang; best to have a dedicated mail-accepting machine that then relays
to the MIMEDefang machine. Even if you could configure the machine to accept
mail in the event of a busy timeout, I think a 10-minute wait for the mail
server to respond would be pretty annoying. :-)
More information about the MIMEDefang