On 04/20/2018 06:44 AM, Wietse Venema wrote:
No, there is contention for the file system.
If you disabled in_flow_delay, turn it back on, please. This allows
the queue manager to push back, though it works only for clients
that make few parallel connections.
Looking at master.cf, there is the column "command + args".
Question: would "nice -n 5 <command>" work?
for example:
pickup unix n - n 60 1 nice -5 pickup
smtp inet n - n - 5 nice -5 smtpd
smtps inet n - n - - nice -5 smtpd
-o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
(submission, too?)
This means that, on disk contention, the other processes have an edge
over the above-listed processes. As I recall, when you have multiple
processes contending for I/O on a device, the process with the higher
working priority gets selected. For writes, though, most of the
requests end up being buffered and the writes actually performed by a
daemon or triggered by close(2) or fsync(2).
(All this goes out the window when one moves to solid-state disk. That
assumes that the system running PostFix can keep up with the inflow; if
not, then my suggestion may still have merit even with SSD.)
In TUNING_README.html, you suggest running a DNS server on the local
machine. Excellent advice. When I configured an instance of Postfix as
a smart relay for a double-handful of CPanel/PLESK servers, I found that
a local DNS server with a large DNS cache had a profound positive effect
on clearing out the mail queue in a timely manner. The computer running
this PostFix instance had eight gigabytes of DRAM, which also let the
Linux file system's cache reduce the accesses to the disk drive.
For high-traffic endpoints (aol.com, gmail.com, yahoo.com, &c) I also
had dedicated senders defined so that I could throttle mail to those
endpoints to prevent triggering anti-spam controls, with the rest going
out the regular way.
