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
