Thank you Viktor.
Answers:
* smtp_connection_cache_on_demand = yes -- this was configured
Changes:
* certs back to defaults
* smtp_tls_loglevel = 1
Before enabling TLS our send rate was about 4K emails per minute -- we
are now seeing 300 to 500 per minute.
The email creation process is sending new mail via a private network.
We are in the middle of an ip address migration so -- email creation
is currently single threaded with 100 uSec delays between emails. I
can increase the concurrency/speed of the email creation process(es)
-- I fear it would only increase the size of the inbound email queue.
Here is a set of delays from the logs:
delays=0.01/2639/25/0.41
delays=0.01/2639/25/0.58
delays=0.01/2641/25/0.58
delays=0.01/2644/25/0.69
delays=0.01/2643/25/0.58
delays=0.01/2640/25/0.57
I scanned a large section of the logs | grep status=sent. These
delays are consistent throughout the peak demand period.
Best, Greg
On Tue, May 21, 2024 at 7:12 AM Viktor Dukhovni via Postfix-users
<postfix-users@postfix.org> wrote:
>
> On Tue, May 21, 2024 at 06:51:08AM -0500, Greg Sims via Postfix-users wrote:
>
> > Our main.cf contains:
> > smtpd_tls_cert_file = <purchased certs we use with our website>
> > smtpd_tls_key_file = <key for above>
> > smtpd_tls_security_level = none
>
> There's no point in configuring SMTP server certificates when TLS is
> disabled in the SMTP server. If the idea is to make tlsproxy(8)
> "happy", then try: "smtpd_tls_cert_file = none" and leave the key file
> setting at its default empty value.
>
> > smtp_tls_security_level = may
>
> Fine.
>
> > We have used connection caching in the past so we added:
> > * smtp_tls_connection_reuse=yes
>
> Presumably, you also have "smtp_connection_cache_on_demand = yes".
>
> > * uncommented tlsproxy / maxproc = 0 in master.cf
> > * commented smtp_tls_loglevel -- no logging as a result
>
> Level 1 is recommended when TLS is enabled. The additional logging
> overhead is quite modest.
>
> > The outbound message transfer rate of our configuration is less than
> > 500 emails per minute. I noted the following:
> >
> > * we have four entries in master.cf for smtp -- each has a
> > unique ip address with maxproc=32; these are used with randmap{} in
> > main.cf
>
> Fine.
>
> > * queuing of inbound email is high
> > * the inbound email queue contains over 3,000 emails
>
> So that's ~6 minutes of backlog... Plausibly due to downstream rate
> and/or concurrency limits
>
> > * email average delay is over 400 seconds and 1,100
> > seconds for google.com where most of the email is delivered
>
> If the backlog isn't growing, can you post the averages of the
> delays=a/b/c/d components?
>
> > * htop shows
> > * cpu utilization is low with Load average under 0.10 on
> > four physical processors and 4GB memory / 500MB used
>
> CPU was unlikely to be the problem.
>
> > * only one tlsproxy process running -- the highest cpu
> > utilization process most of the time
>
> Fine. More would be spawned if it got too busy to serve client requests
> in a timely manner.
>
> > * 20 processes exist for each of our four ip address/smtp
> > entries in master.cf with maxproc=32
> >
> > I am concerned that the queuing of inbound email is caused by there
> > only being one tlsproxy process.
>
> More plausibly the real issue is message delivery latency to the various
> destinations.
>
> > maxproc=0 seems to allow for an unlimited number. We seem to have
> > plenty of smtp processes as postfix is not starting more of them to
> > reach the maxproc=32.
>
> You could configure separate tlsproxy(8) services for each of the
> smtp(8) transports by overriding "tlsproxy_service_name" in master.cf,
> that will give you multiple tlsproxy(8) processes, but I guessing won't
> change much, if the issue is downstream delays.
>
> --
> Viktor.
> _______________________________________________
> Postfix-users mailing list -- postfix-users@postfix.org
> To unsubscribe send an email to postfix-users-le...@postfix.org
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
