[Mimedefang] performance tuning once again

[tomvo at absi.be]

Hi David,

I just got a hunch: i checked the /var/spool/MIMEDefang directory, looked 
which directories weren't being removed after 2 minutes, and did a fuser 
of those.
and sure enough, processing occupying these directories were invariably 
python processes. I had problems before with lingering python processes, 
but never made the link with these timeout's.

I've restarted now with pyzor disabled, and so far i didn't see any new 
errors (before, i had them almost every 5 minutes).

So I guess (fingers crossed !) that this was my problem, and all my 
tinkering with mimedefang parameters didn't make any difference at all.

thanks for your input though,


regards,
tom.






---------------------------------------------------------------------------
Tom Van Overbeke - ABSI Unix System Engineer
email: tomvo at absi.be
Tel: +32 2 333 40 00 - Fax: +32 2 332 34 69
website: http://www.absi.be
---------------------------------------------------------------------------





"David F. Skoll" <dfs at roaringpenguin.com>
Sent by: mimedefang-bounces at lists.roaringpenguin.com
16/10/2005 16:40
Please respond to mimedefang
 
        To:     mimedefang at lists.roaringpenguin.com
        cc: 
        Subject:        Re: [Mimedefang] performance tuning once again


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)
> MX_QUEUE_SIZE=100

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.
> MX_BUSY=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. :-)

Regards,

David.
_______________________________________________
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list
MIMEDefang at lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang