> On 2017-01-25, Mark Elkins <mje@???> wrote:
> > I think the other thing to consider is setting "smtp_accept_max =
> > 10" means you can only process up to 10 e-mails at one time. If
> > you are doing a number of checks, Virus, multiple blacklist checks
> > - these tests can take a while - possible a meaningful amount
> > of seconds each. Just bear that in mind. You probably want to
> > increase"smtp_accept_max" quite a bit. I've also changed my "log
> > selector":
>
> If you're doing lots of checks there's no reason to have accept max
> significantly higher than the number of CPU cores in your server (more
> than twice would probably be excessive), or so high that your server
> runs out of RAM, because after a certain point running more checks in
> parallel decreases throughput, and you'll do better telling the extra
> senders to come back later.
Many checks may take time but not CPU and memory; the classical
example is DNS blocklist checks, which must query external DNS servers.
Even simply verifying MAIL FROM addresses may take some time for DNS
lookups (possibly a lot of time if some spam sending machine is trying
to send you spam with a MAIL FROM of a domain with broken DNS).
The other thing to consider for smtp_accept_max is that there is no
guarantee that the SMTP sender connecting to you will act rapidly. The
sending machine may be behind a contended or high-latency link, and it
may be under load itself. For that matter there is no guarantee that
a SMTP sender will promptly disconnect after it has sent a message;
it might have another to send but take some time to get it ready, or it
might even opportunistically hold the connection to you open for a bit
in case another message shows up (some machines that connect to our
external MX gateway do this).
All in all, there is no certainty that all your SMTP connections
are busy doing CPU/memory expensive operations at the same time. They
could, especially if you're unlucky, but for many machines receiving email
from the outside world it is probably unlikely. And if controlling and
limiting machine load is what you're concerned about, there are a variety
of alternates besides smtp_accept_max, for example smtp_load_reserve.
(There is also directly limiting how many processes can be doing expensive
operations at the same time, using various techniques. You may have to
build a system to do this yourself, but my experience is that if you are
saturating a modern system this way, you have a sufficiently demanding
and high volume of email that you're in a fairly unusual situation[*].)
- cks
[*: we accept tens of thousands of messages a day on several year
old basic hardware, while doing relatively expensive processing
on all of them. The machines involved are barely breaking a
sweat.
]
