On Fri, Sep 26, 2014 at 12:59:58AM +0000, Viktor Dukhovni wrote: > On Thu, Sep 25, 2014 at 05:34:46PM -0700, Will Yardley wrote: > > > 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").
Interesting, as you may remember, my last problem was also log-related. The system is using rsyslog, logging locally and to two remote syslog servers. The local files have '-' before them for the most part in rsyslog.conf, e.g., mail.* -/var/log/maillog $ netstat -an | grep log unix 103 [ ] DGRAM 15438 /dev/log new: $ time echo 'test' | logger real 0m0.016s user 0m0.000s sys 0m0.017s old: $ time echo 'test' | logger real 0m0.003s user 0m0.000s sys 0m0.002s > If the queue manager is not keeping with mail arrival into the > incoming queue, in_flow_delay may introduce 1s pauses at this point. I tried setting that to '0' (it was set to 1), but didn't seem to make a noticeable difference. > Perhaps trivial-rewrite is slow, which may happen if transport > queries are made via a high latency service (LDAP performance > issues?). Yeah, it's something I need to look at, though the backend systems are the same ones the old system had been talking to before the cut-over. Is there any potential benefit to increasing the number of max processes for trivial-rewrite and / or proxymap? $default_process_limit is 500, but there are several different smtpd instances. > > 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. That probably doesn't need to be in there, but the file currently only contains a single (comment) line. It was used for a migration process many years ago. I will try running strace on an smtpd process and see if that helps identify anything. w
