Murray S. Kucherawy wrote:
> On Tue, 25 Jan 2011, Gary Mills wrote:
>
> This again shows thread exhaustion. It appears to be caused by the
> asynchronous resolver becoming wedged, meaning jobs that need DNS
> answers are timing out waiting for them; enough of a backlog of these
> forms that no more threads can be allocated (libmilter creates a thread
> per SMTP client) and eventually exits the entire process when it fails
> to do so enough times.
One workaround is the libmilter with a pool of workers. Libmilter creates a small number of threads
at start-up and allocates a thread to handle one sendmail command, instead of creating one thread
per SMTP client. This means a new thread will be created only it the filter effectively need a new
thread to handle a sendmail command, not a new SMTP client.
This can dramatically decrease the number of threads in the filter.
To use this alternative model, you need just to recompile the libmilter and enable this feature :
APPENDDEF(`conf_libmilter_ENVDEF',`-D_FFR_WORKER_MODEL')
APPENDDEF(`conf_libmilter_ENVDEF',`-D_FFR_USE_POLL')
The second line will replace all select calls inside libmilter (libmilter, not the filter), by poll.
You will need to recompile all your milters if you replace your libmilter, mainly if they're linked
against a static version of libmilter.
Well, this can dramatically decrease the number of threads in the filter, if the inactivity reason
is delays waiting for a sendmail command, or by some work being done by other "CPU pig filter" or
"delay pig filter", not if they're waiting for something internal to the filter.
--
---------------------------------------------------------------
Jose Marcio MARTINS DA CRUZ http://j-chkmail.ensmp.fr
Ecole des Mines de Paris
60, bd Saint Michel 75272 - PARIS CEDEX 06
mailto:Jose-Marcio.Martins_at_mines-paristech.fr
Received on Wed Jan 26 2011 - 09:59:54 PST