On Thu, Sep 25, 2014 at 05:34:46PM -0700, Will Yardley wrote:
> We upgraded recently from 2.3.3 (RHEL5 stock Postfix) to 2.6.6 (RHEL6
> stock Postfix). The settings, including $smtpd_sender_restrictions,
> $smtpd_recipient_restrictions, and the ldap lookup maps (as well as the
> backend LDAP servers) are the same.
>
> The new systems are faster hardware, and faster disks, however, I notice
> a very slight delay (maybe 1s) on the newer system after RCPT TO (it's
> perceptible visually if you telnet to port 25 and send a message).
> There's a local instance of unbound and rbldnsd, though I don't think
> DNS lookups are the issue, since the sending hosts are both in
> $mynetworks and explicitly whitelisted (they're also exempted from
> rate-limiting).
Postfix creates the queue file when the first recipient is accepted.
Does the delay happen also on subsequent RCPT TO commands, or just
the first? This is also when smtpd logs the "client=..." log entry.
Is your syslog logging synchronously? Is the /dev/log socket
"dgram" or "stream" (it should be "dgram").
If the queue manager is not keeping with mail arrival into the
incoming queue, in_flow_delay may introduce 1s pauses at this point.
Perhaps trivial-rewrite is slow, which may happen if transport
queries are made via a high latency service (LDAP performance
issues?).
> There are a lot of LDAP lookups involved, and I'll look at profiling
> those and seeing if indices need to be added on any fields, but the same
> configuration was snappier with the older version with the same backend
> hosts.
> smtpd_recipient_restrictions =
> check_recipient_access regexp:/etc/postfix/no_sender_rte,
> check_recipient_access hash:/etc/postfix/auto_generated_files/rcpt_blocks,
> check_recipient_access hash:/etc/postfix/hold-users,
What are these "hold-users"? What fraction of mail is placed on
HOLD? Mail that enters the HOLD queue may not get considered as
processed for purposes of in_flow_delay resource accounting.
--
Viktor.
