On Sat, May 11, 2013 at 06:33:22PM -0400, Wietse Venema wrote:
> Patrik Rak:
> > > This largely solves the problem, and is much simpler to configure:
> > >
> > > # Out of a total of $default_process_limit (100), leaving 20
> > > # for fresh mail. Adjust appropriately when master.cf or
> > > # default_process_limit are changed.
> > > #
> > > smtp_deferred_concurrency_limit = 80
>
> Even simpler: stop reading the deferred queue when more than N% of
> the maximal number of recipient slots is from deferred mail.
This does not address Patrick's stated goal of avoiding process
saturation in the smtp transport by slow mail to bogus destinations.
(Similar to my 2001 analysis that motivated "relay" for inbound mail
and taught me the importance of recipient validation).
Rather, it adresses active limit exhaustion. The idea is perhaps
a good one anyway. Reserve some fraction of the active queue limits
for new mail, so that when enough deferred mail is in core, only new
mail is processed along with the already deferred mail.
A separate mechanism is still needed to avoid using all ~100 smtp
transport delivery processes for deferred mail. This means that
Patrick would need to think about whether the existing algorithm
can be extended to take limits on process allocation to deferred
mail into account.
I sympathise with the concern about the internal cost, but if the
solution adds substantial user-visible complexity I contend that
it is pointless, and the users who need this (the sites that accept
subscriptions via HTTP, ...) can just create a multi-instance
config, it is simple enough to do.
--
Viktor.
