[Mimedefang] Milter: connect: host= temp failing commands (busy servers tuning)

[Stephane Lentz]

On Tue, Jul 01, 2003 at 09:56:35PM -0400, David F. Skoll wrote:
> On Wed, 2 Jul 2003, Stephane Lentz wrote:
> 
> > I had 932 messages 'mfconnect: No free slave' in a day.
> 
> > It seems that I should increase MX_MINIMUM & MX_MAXIMUM (too low :
> > default values).
> 
> In general, I recommend MX_MAXIMUM be about the amount of RAM in your
> system divided by 20MB.  So on a 512MB system, an MX_MAXMIMUM of 26 or so
> should be safe.  If you usually have more than MX_MINIMUM slaves running,
> then bump MX_MINIMUM up to a couple more than the "usual" number of
> active slaves.

=> Ok. The temp rejections still arise on busy periods from time to time even after
increasing MX_MAXMIMUM to 20. I Will try 26.
I'm still noticing 'Error from multiplexor: error: No free slaves' at the
time sendmail logs some Milter: connect: host=....  addr=..., temp failing commands

I wonder if the Timeout for connecting to a filter shouldn't be
increased. 
The C parameter for INPUT_MAIL_FILTER is not used currently for the
MIMEDEFang filter definition in the sendmail.mc .  
I'm using the classical : 
NPUT_MAIL_FILTER(`mimedefang', `S=unix:/var/spool/MIMEDefang/mimedefang.sock, F=T,
T=S:1m;R:1m;E:5m')dnl

README.libmilter says 'C' is supposed to be set to 5m. 
What's your recommandation regarding this parameter ?

Letter          Meaning
  C             Timeout for connecting to a filter (if 0, use system

I will try to activate MX_STATS to get more information about
multiplexor's usage.  

> > I should consider a RAM-based spool directory too I guess.
> 
> Absolutely.  That will help a lot.  Also, 2.34's queueing feature might
> help (I can understand why you want to wait for 2.35.)
> 

=> 2.35 out so upgrade is planned. Ram-based spool too. 

Regards, 

SL/
---
Stephane Lentz 
Alcanet International, Internet Services