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: [EMAIL PROTECTED] Tel: +32 2 333 40 00 - Fax: +32 2 332 34 69 website: http://www.absi.be --------------------------------------------------------------------------- "David F. Skoll" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 16/10/2005 16:40 Please respond to mimedefang To: [email protected] cc: Subject: Re: [Mimedefang] performance tuning once again [EMAIL PROTECTED] 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 [email protected] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang _______________________________________________ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list [email protected] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
