[Mimedefang] right value for MX_MAXIMUM

[Joseph Brennan]

> I am having the system with sendmail, mimedefang and spamassassin.
> Mimedefang is running with the below options.

Same here.


> MX_MINIMUM=2
> MX_MAXIMUM=80

We are using

MX_MINIMUM=40
MX_MAXIMUM=50

I think MX_MINIMUM is greater than we need. The reason we pushed it up high 
was that the previous hardware we used would load-spike when it started up 
new perl processes, so we wanted to avoid starting up multiple slaves when 
a large batch of messages suddenly comes in. Better to have some idle 
slaves ready to take them. The new hardware does not have that problem, but 
the idle processes don't use up any significant resources so we left it 
alone pending further analysis at a future date.



> In a day I am getting the below error multiple times. By looking at
> the md-mx-ctrl rawstats, all the 80 slaves are busy at that time. We
> are receiving around 500 e-mails in a minute.
>
> mimedefang-multiplexor[2500]: No free slaves

Ouch.

Unless that's rare it means something is not sized correctly. Running 80 
busy processes at once sounds pretty intense. What's the system load when 
that happens? How long do they take to handle each message? I wonder if 
something in the filter is running slow. As Kevin McGrail replied, it does 
all depend on what the hardware can do, and I like the idea of timing the 
processes.

As you can see we hold it to 50. We did get "No free slaves" yesterday for 
9 seconds on one of the ten hosts. Most days it does not happen.



> I read that the e-mails sent during this time would be retried by the
> other MTA automatically, but I am seeing it as lost.

Yes, MD tells sendmail to give a temp fail, and if the remote system 
implements SMTP it will re-try. But you end up with delayed mail and user 
complaints, at best. If you receive from end-user devices some of them do 
not know how to queue and re-try and that is where temp fail becomes a 
permanent fail.



-- Joseph Brennan, Columbia U I T