2004-04-27 08:12:43 +04:00
|
|
|
<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN"
|
|
|
|
|
"http://www.w3.org/TR/html4/loose.dtd">
|
|
|
|
|
|
|
|
|
|
<html>
|
|
|
|
|
|
|
|
|
|
<head>
|
|
|
|
|
|
|
|
|
|
<title>Postfix Performance Tuning</title>
|
|
|
|
|
|
|
|
|
|
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
|
|
|
|
|
|
|
|
|
|
</head>
|
|
|
|
|
|
|
|
|
|
<body>
|
|
|
|
|
|
|
|
|
|
<h1><img src="postfix-logo.jpg" width="203" height="98" alt="">
|
|
|
|
|
Postfix Performance Tuning</h1>
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
|
|
|
|
|
|
|
|
<h2>Purpose of Postfix performance tuning </h2>
|
|
|
|
|
|
|
|
|
|
<p> The hints and tips in this document help you improve the
|
|
|
|
|
performance of Postfix systems that already work. If your Postfix
|
|
|
|
|
system is unable to receive or deliver mail, then you need to solve
|
|
|
|
|
those problems first, using the DEBUG_README document as guidance.
|
|
|
|
|
|
|
|
|
|
<p> For tuning external content filter performance, first read the
|
|
|
|
|
respective information in the FILTER_README and SMTPD_PROXY_README
|
|
|
|
|
documents. Then make sure to avoid latency in the content filter
|
|
|
|
|
code. As much as possible avoid performing queries against external
|
|
|
|
|
data sources with a high or highly variable delay. Your content
|
|
|
|
|
filter will run with a small concurrency to avoid CPU/memory
|
|
|
|
|
starvation, and if any latency creeps in, content filter throughput
|
|
|
|
|
will suffer. High volume environments should avoid RBL lookups,
|
|
|
|
|
complex database queries and so on. </p>
|
|
|
|
|
|
|
|
|
|
<p>Topics on mail receiving performance: </p>
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
|
|
|
|
<li> <a href="#server_tips">General mail receiving performance tips</a>
|
|
|
|
|
|
|
|
|
|
<li> <a href="#speedup">Doing more work with your SMTP server processes</a>
|
|
|
|
|
|
|
|
|
|
<li> <a href="#slowdown">Slowing down SMTP clients that make many errors</a>
|
|
|
|
|
|
|
|
|
|
<li> <a href="#conn_limit">Measures against clients that make too many connections</a>
|
|
|
|
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<p>Topics on mail delivery performance: </p>
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
|
|
|
|
<li> <a href="#mailing_tips">General mail delivery performance tips</a>
|
|
|
|
|
|
|
|
|
|
<li> <a href="#hammer">Tuning the frequency of deferred mail delivery attempts</a>
|
|
|
|
|
|
|
|
|
|
<li> <a href="#rope">Tuning the number of simultaneous deliveries</a>
|
|
|
|
|
|
|
|
|
|
<li> <a href="#rcpts">Tuning the number of recipients per delivery</a>
|
|
|
|
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<p>Other Postfix performance tuning topics: </p>
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
|
|
|
|
<li> <a href="#proc_limit">Tuning the number of Postfix processes</a>
|
|
|
|
|
|
|
|
|
|
<li> <a href="#file_limit">Tuning the number of open files or
|
|
|
|
|
sockets</a>
|
|
|
|
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<p> The following tools can be used to measure mail system performance
|
|
|
|
|
under artificial loads. They are normally not installed with Postfix.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
|
|
|
|
<li> <a href="smtp-source.1.html">smtp-source, SMTP/LMTP message
|
|
|
|
|
generator</a>
|
|
|
|
|
|
|
|
|
|
<li> <a href="smtp-sink.1.html">smtp-sink, SMTP/LMTP message dump
|
|
|
|
|
</a>
|
|
|
|
|
|
|
|
|
|
<li> <a href="qmqp-source.1.html">qmqp-source, QMQP message generator
|
|
|
|
|
</a>
|
|
|
|
|
|
|
|
|
|
<li> <a href="qmqp-sink.1.html">qmqp-sink, QMQP message dump </a>
|
|
|
|
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<h2><a name="server_tips">General mail receiving performance
|
|
|
|
|
tips</a></h2>
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
|
|
|
|
<li> <p> Read and understand the maildrop queue, incoming queue,
|
|
|
|
|
and active queue discussions in the QSHAPE_README document. </p>
|
|
|
|
|
|
|
|
|
|
<li> <p> Run a local name server to reduce slow-down due to DNS
|
|
|
|
|
lookups. If you run multiple Postfix systems, point each local name
|
|
|
|
|
server to a shared forwarding server to reduce the number of lookups
|
|
|
|
|
across the upstream network link. </p>
|
|
|
|
|
|
|
|
|
|
<li> <p> Eliminate unnecessary LDAP lookups, by specifying a domain
|
|
|
|
|
filter. This eliminates lookups for addresses in remote domains,
|
|
|
|
|
and eliminates lookups of partial addresses. See ldap_table(5) for
|
|
|
|
|
details. </p>
|
|
|
|
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<p> When Postfix responds slowly to SMTP clients: </p>
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
|
|
|
|
<li> <p> <a href="DEBUG_README.html#logging">Look for obvious signs
|
|
|
|
|
of trouble</a> as described in the DEBUG_README document, and
|
|
|
|
|
eliminate those problems first. </p>
|
|
|
|
|
|
|
|
|
|
<li> <p> Turn off your header_checks and body_checks patterns and
|
|
|
|
|
see if the problem goes away. </p>
|
|
|
|
|
|
|
|
|
|
<li> <p> <a href="DEBUG_README.html#no_chroot">Turn off chroot
|
|
|
|
|
operation</a> as described in the DEBUG_README document and see
|
|
|
|
|
if the problem goes away. </p>
|
|
|
|
|
|
|
|
|
|
<li> <p> If Postfix logs the SMTP client as "unknown" then you have
|
|
|
|
|
a name service problem: the name server is bad, or the resolv.conf
|
|
|
|
|
file contains bad information, or some packet filter is blocking
|
|
|
|
|
the DNS requests or replies. </p>
|
|
|
|
|
|
|
|
|
|
<li> <p> If the number of smtpd(8) processes has reached the process
|
|
|
|
|
limit as specified in master.cf, new SMTP clients must wait until
|
|
|
|
|
a process becomes available. Increase the number of processes if
|
|
|
|
|
memory permits. See the instructions given under "<a
|
|
|
|
|
href="#proc_limit">Tuning the number of Postfix processes</a>".
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<h2><a name="speedup">Doing more work with your SMTP server
|
|
|
|
|
processes</a></h2>
|
|
|
|
|
|
|
|
|
|
<p> With Postfix versions 2.0 and earlier, the smtpd(8) server
|
|
|
|
|
pauses before reporting an error to an SMTP client. The idea is
|
|
|
|
|
called tar pitting. However, these delays also slow down Postfix.
|
|
|
|
|
When the smtpd(8) server replies slowly, sessions take more time,
|
|
|
|
|
so that more smtpd(8) server processes are needed to handle the
|
|
|
|
|
load. When your Postfix smtpd(8) server process limit is reached,
|
|
|
|
|
new clients must wait until a server process becomes available.
|
|
|
|
|
This means that all clients experience poor performance. </p>
|
|
|
|
|
|
|
|
|
|
<p> You can speed up the handling of smtpd(8) server error replies
|
|
|
|
|
by turning off the delay: </p>
|
|
|
|
|
|
|
|
|
|
<blockquote>
|
|
|
|
|
<pre>
|
|
|
|
|
/etc/postfix/main.cf:
|
|
|
|
|
# Not needed with Postfix 2.1
|
|
|
|
|
smtpd_error_sleep_time = 0
|
|
|
|
|
</pre>
|
|
|
|
|
</blockquote>
|
|
|
|
|
|
|
|
|
|
<p> With the above setting, Postfix 2.0 and earlier can serve more
|
|
|
|
|
SMTP clients with the same number SMTP server processes. The next
|
|
|
|
|
section describes how Postfix deals with clients that make a large
|
|
|
|
|
number of errors. </p>
|
|
|
|
|
|
|
|
|
|
<h2><a name="slowdown"> Slowing down SMTP clients that make many errors</a></h2>
|
|
|
|
|
|
|
|
|
|
<p> The Postfix smtpd(8) server maintains a per-session error count.
|
|
|
|
|
The error count is reset when a message is transferred successfully,
|
|
|
|
|
and is incremented when a client request is unrecognized or
|
|
|
|
|
unimplemented, when a client request violates <a
|
|
|
|
|
href="SMTPD_ACCESS_README.html">access restrictions</a>, or when
|
|
|
|
|
some other error happens. </p>
|
|
|
|
|
|
|
|
|
|
<p> As the per-session error count increases, the smtpd(8) server
|
|
|
|
|
changes behavior and begins to insert delays into the responses.
|
|
|
|
|
The idea is to slow down a run-away client in order to limit resource
|
|
|
|
|
usage. The behavior is Postfix version dependent. </p>
|
|
|
|
|
|
|
|
|
|
<p> IMPORTANT: These delays slow down Postfix, too. When too much
|
|
|
|
|
delay is configured, the number of simultaneous SMTP sessions will
|
|
|
|
|
increase until it reaches the smtpd(8) server process limit, and new
|
|
|
|
|
SMTP clients must wait until an smtpd(8) server process becomes available.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p> Postfix version 2.1 and later:</p>
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
|
|
|
|
<li> <p> When the error count reaches $smtpd_soft_error_limit
|
|
|
|
|
(default: 10), the Postfix smtpd(8) server delays all non-error and
|
|
|
|
|
error responses by $smtpd_error_sleep_time seconds (default: 1
|
|
|
|
|
second). </p>
|
|
|
|
|
|
|
|
|
|
<li><p>When the error count reaches $smtpd_hard_error_limit
|
|
|
|
|
(default: 20) the Postfix smtpd(8) server breaks the connection. </p>
|
|
|
|
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<p> Postfix version 2.0 and earlier:</p>
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
|
|
|
|
<li> <p> When the error count is less than $smtpd_soft_error_limit
|
|
|
|
|
(default: 10) the Postfix smtpd(8) server delays all error replies by
|
|
|
|
|
$smtpd_error_sleep_time (1 second with Postfix 2.0, 5 seconds with
|
|
|
|
|
Postfix 1.1 and earlier). </p>
|
|
|
|
|
|
|
|
|
|
<li> <p> When the error count reaches $smtpd_soft_error_limit,
|
|
|
|
|
the Postfix smtpd(8) server delays all responses by "error count"
|
|
|
|
|
seconds or $smtpd_error_sleep_time, whichever is more. </p>
|
|
|
|
|
|
|
|
|
|
<li><p>When the error count reaches $smtpd_hard_error_limit
|
|
|
|
|
(default: 20) the Postfix smtpd(8) server breaks the connection. </p>
|
|
|
|
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<h2><a name="conn_limit">Measures against clients that make too many connections</a></h2>
|
|
|
|
|
|
2007-05-19 20:27:18 +04:00
|
|
|
<p> Note: these features use the Postfix anvil(8) service, introduced
|
|
|
|
|
with Postfix version 2.2. </p>
|
2004-04-27 08:12:43 +04:00
|
|
|
|
|
|
|
|
<p> The Postfix smtpd(8) server can limit the number of simultaneous
|
2007-05-19 20:27:18 +04:00
|
|
|
connections from the same SMTP client, as well as the connection
|
|
|
|
|
rate and the rate of certain SMTP commands from the same client.
|
2004-04-27 08:12:43 +04:00
|
|
|
These statistics are maintained by the anvil(8) server (translation:
|
|
|
|
|
if anvil(8) breaks, then connection limits stop working). </p>
|
|
|
|
|
|
2007-05-19 20:27:18 +04:00
|
|
|
<p> IMPORTANT: These limits must not be used to regulate legitimate
|
|
|
|
|
traffic: mail will suffer grotesque delays if you do so. The limits
|
|
|
|
|
are designed to protect the smtpd(8) server against abuse by
|
|
|
|
|
out-of-control clients. </p>
|
2004-04-27 08:12:43 +04:00
|
|
|
|
2007-05-19 20:27:18 +04:00
|
|
|
<blockquote>
|
2004-04-27 08:12:43 +04:00
|
|
|
|
2007-05-19 20:27:18 +04:00
|
|
|
<dl>
|
2004-04-27 08:12:43 +04:00
|
|
|
|
2007-05-19 20:27:18 +04:00
|
|
|
<dt> smtpd_client_connection_count_limit (default: 50) </dt> <dd>
|
|
|
|
|
The maximum number of connections than an SMTP client may make
|
|
|
|
|
simultaneously. </dd>
|
2005-08-19 01:00:20 +04:00
|
|
|
|
2007-05-19 20:27:18 +04:00
|
|
|
<dt> smtpd_client_connection_rate_limit (default: no limit) </dt>
|
|
|
|
|
<dd> The maximum number of connections that an SMTP client may make
|
|
|
|
|
in the time interval specified with anvil_rate_time_unit (default:
|
|
|
|
|
60s). </dd>
|
2005-08-19 01:00:20 +04:00
|
|
|
|
2007-05-19 20:27:18 +04:00
|
|
|
<dt> smtpd_client_message_rate_limit (default: no limit) </dt> <dd>
|
|
|
|
|
The maximum number of message delivery requests that an SMTP client
|
|
|
|
|
may make in the time interval specified with anvil_rate_time_unit
|
|
|
|
|
(default: 60s). </dd>
|
2004-04-27 08:12:43 +04:00
|
|
|
|
2007-05-19 20:27:18 +04:00
|
|
|
<dt> smtpd_client_recipient_rate_limit (default: no limit) </dt>
|
|
|
|
|
<dd> The maximum number of recipient addresses that an SMTP client
|
|
|
|
|
may specify in the time interval specified with anvil_rate_time_unit
|
|
|
|
|
(default: 60s). </dd>
|
2004-04-27 08:12:43 +04:00
|
|
|
|
2007-05-19 20:27:18 +04:00
|
|
|
<dt> smtpd_client_new_tls_session_rate_limit (default: no limit)
|
|
|
|
|
</dt> <dd> The maximum number of new TLS sessions (without using
|
|
|
|
|
the TLS session cache) that an SMTP client may negotiate in the
|
|
|
|
|
time interval specified with anvil_rate_time_unit (default: 60s).
|
|
|
|
|
</dd>
|
2004-04-27 08:12:43 +04:00
|
|
|
|
2007-05-19 20:27:18 +04:00
|
|
|
<dt> smtpd_client_event_limit_exceptions (default: $mynetworks)
|
|
|
|
|
</dt> <dd> SMTP clients that are excluded from connection and rate
|
|
|
|
|
limits specified above. </dd>
|
|
|
|
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
</blockquote>
|
2004-04-27 08:12:43 +04:00
|
|
|
|
|
|
|
|
<h2><a name="mailing_tips">General mail delivery performance tips</a></h2>
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
|
|
|
|
<li> <p> Read and understand the maildrop queue, incoming queue,
|
|
|
|
|
active queue and deferred queue discussions in the QSHAPE_README
|
|
|
|
|
document. </p>
|
|
|
|
|
|
|
|
|
|
<li> <p> In case of slow delivery, run the qshape tool as described
|
|
|
|
|
in the QSHAPE_README document. </p>
|
|
|
|
|
|
|
|
|
|
<li> <p> Submit multiple recipients per message instead of submitting
|
|
|
|
|
messages with only a few recipients. </p>
|
|
|
|
|
|
|
|
|
|
<li> <p> Submit mail via SMTP instead of /usr/sbin/sendmail. You
|
|
|
|
|
may have to adjust the smtpd_recipient_limit parameter setting.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<li> <p> Don't overwhelm the disk with mail submissions. Optimize
|
|
|
|
|
the mail submission rate by tuning the number of parallel submissions
|
|
|
|
|
and/or by tuning the Postfix in_flow_delay parameter setting. </p>
|
|
|
|
|
|
|
|
|
|
<li> <p> Run a local name server to reduce slow-down due to DNS
|
|
|
|
|
lookups. If you run multiple Postfix systems, point each local name
|
|
|
|
|
server to a shared forwarding server to reduce the number of lookups
|
|
|
|
|
across the upstream network link. </p>
|
|
|
|
|
|
|
|
|
|
<li> <p> Reduce the smtp_connect_timeout and smtp_helo_timeout
|
|
|
|
|
values so that Postfix does not waste lots of time connecting
|
2005-08-19 01:00:20 +04:00
|
|
|
to non-responding remote SMTP servers. </p>
|
2004-04-27 08:12:43 +04:00
|
|
|
|
|
|
|
|
<li> <p> Use a dedicated mail delivery transport for problematic
|
|
|
|
|
destinations, with reduced timeouts and with adjusted concurrency.
|
|
|
|
|
See "<a href="#rope">Tuning the number of simultaneous deliveries</a>"
|
|
|
|
|
below.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<li> <p> Use a fallback_relay host for mail that cannot be delivered
|
|
|
|
|
upon the first attempt. This "graveyard" machine can use shorter
|
|
|
|
|
retry times for difficult to reach destinations. See "<a
|
|
|
|
|
href="#hammer">Tuning the frequency of deferred mail delivery
|
|
|
|
|
attempts</a>" below. </p>
|
|
|
|
|
|
|
|
|
|
<li> <p> Speed up disk updates with a large (64MB) persistent write
|
|
|
|
|
cache. This allows disk updates to be sorted for optimal access
|
|
|
|
|
speed without compromising file system integrity when the system
|
|
|
|
|
crashes. </p>
|
|
|
|
|
|
|
|
|
|
<li> <p> Use a solid-state disk (a persistent RAM disk). This
|
|
|
|
|
is an expensive solution that should be used in combination
|
|
|
|
|
with short SMTP timeouts and a fallback_relay "graveyard"
|
|
|
|
|
machine that delivers mail for problem destinations. </p>
|
|
|
|
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<h2><a name="rope">Tuning the number of simultaneous deliveries</a></h2>
|
|
|
|
|
|
|
|
|
|
<p> Although Postfix can be configured to run 1000 SMTP client
|
|
|
|
|
processes at the same time, it is rarely desirable that it makes
|
|
|
|
|
1000 simultaneous connections to the same remote system. For this
|
|
|
|
|
reason, Postfix has safety mechanisms in place to avoid this
|
|
|
|
|
so-called "thundering herd" problem. </p>
|
|
|
|
|
|
|
|
|
|
<p> The Postfix queue manager implements the analog of the TCP slow
|
|
|
|
|
start flow control strategy: when delivering to a site, send a
|
|
|
|
|
small number of messages first, then increase the concurrency as
|
|
|
|
|
long as all goes well; reduce concurrency in the face of congestion.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
|
|
|
|
<li> <p> The initial_destination_concurrency parameter (default: 5)
|
|
|
|
|
controls how many messages are initially sent to the same destination
|
|
|
|
|
before adapting delivery concurrency. Of course, this setting is
|
|
|
|
|
effective only as long as it does not exceed the process limit and
|
|
|
|
|
the destination concurrency limit for the specific mail transport
|
|
|
|
|
channel. </p>
|
|
|
|
|
|
|
|
|
|
<li> <p> The default_destination_concurrency_limit parameter (default:
|
|
|
|
|
20) controls how many messages may be sent to the same destination
|
|
|
|
|
simultaneously. You can override this setting for specific message
|
|
|
|
|
delivery transports by taking the name of the master.cf entry
|
|
|
|
|
and appending "_destination_concurrency_limit". </p>
|
|
|
|
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<p> Examples of transport specific concurrency limits are: </p>
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
|
|
|
|
<li> <p> The local_destination_concurrency_limit parameter (default:
|
|
|
|
|
2) controls how many messages are delivered simultaneously to the
|
|
|
|
|
same local recipient. The recommended limit is low because delivery
|
|
|
|
|
to the same mailbox must happen sequentially, so massive parallelism
|
|
|
|
|
is not useful. Another good reason to limit delivery concurrency
|
|
|
|
|
to the same recipient: if the recipient has an expensive shell
|
|
|
|
|
command in her .forward file, or if the recipient is a mailing list
|
|
|
|
|
manager, you don't want to run too many instances of those processes
|
2007-05-19 20:27:18 +04:00
|
|
|
at the same time. </p>
|
2004-04-27 08:12:43 +04:00
|
|
|
|
|
|
|
|
<li> <p> The default smtp_destination_concurrency_limit of 20 seems
|
|
|
|
|
enough to noticeably load a system without bringing it to its knees.
|
|
|
|
|
Be careful when changing this to a much larger number. </p>
|
|
|
|
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<p> The above default values of the concurrency limits work well
|
|
|
|
|
in a broad range of situations. Knee-jerk changes to these parameters
|
|
|
|
|
in the face of congestion can actually make problems worse.
|
|
|
|
|
Specifically, large destination concurrencies should never be the
|
|
|
|
|
default. They should be used only for transports that deliver mail
|
|
|
|
|
to a small number of high volume domains. </p>
|
|
|
|
|
|
|
|
|
|
<p> A common situation where high concurrency is called for is on
|
|
|
|
|
gateways relaying a high volume of mail from between the Internet
|
|
|
|
|
and an intranet mail environment. Approximately half the mail
|
|
|
|
|
(assuming equal volumes inbound and outbound) will be destined
|
|
|
|
|
for the internal mail hubs. Since the internal mail hubs will be
|
|
|
|
|
receiving all external mail exclusively from the gateway, it is
|
|
|
|
|
reasonable to configure the gateway to make greater demands on the
|
|
|
|
|
capacity of the internal SMTP servers. </p>
|
|
|
|
|
|
|
|
|
|
<p> The tuning of the inbound concurrency limits need not be trial
|
|
|
|
|
and error. A high volume capable mailhub should be able to easily
|
|
|
|
|
handle 50 or 100 (rather than the default 20) simultaneous connections,
|
|
|
|
|
especially if the gateway forwards to multiple MX hosts. When all
|
|
|
|
|
MX hosts are up and accepting connections in a timely fashion,
|
|
|
|
|
throughput will be high. If any MX host is down and completely
|
|
|
|
|
unresponsive, the average connection latency rises to at least 1/N
|
|
|
|
|
* $smtp_connection_timeout, if there are N MX hosts. This limits
|
|
|
|
|
throughput to at most the destination concurrency * N /
|
|
|
|
|
$smtp_connection_timeout. </p>
|
|
|
|
|
|
|
|
|
|
<p> For example, with a destination concurrency of 100 and 2 MX
|
|
|
|
|
hosts, each host will handle up to 50 simultaneous connections. If
|
|
|
|
|
one MX host is down and the default SMTP connection timeout is 30s,
|
|
|
|
|
the throughput limit is 100 * 2 / 30 ~= 6 messages per second. This
|
|
|
|
|
suggests that high volume destinations with good connectivity and
|
|
|
|
|
multiple MX hosts need a lower connection timeout, values as low
|
|
|
|
|
as 5s or even 1s can be used to prevent congestion when one or
|
|
|
|
|
more, but not all MX hosts are down. </p>
|
|
|
|
|
|
|
|
|
|
<p> If necessary, set a higher transport_destination_concurrency_limit
|
|
|
|
|
(in main.cf since this is a queue manager parameter) and a lower
|
|
|
|
|
smtp_connection_timeout (with a "-o" override in master.cf since
|
|
|
|
|
this parameter has no per-transport name) for the relay transport
|
|
|
|
|
and any transports dedicated for specific high volume destinations.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h2><a name="rcpts">Tuning the number of recipients per delivery</a></h2>
|
|
|
|
|
|
|
|
|
|
<p> The default_destination_recipient_limit parameter (default:
|
|
|
|
|
50) controls how many recipients a Postfix delivery agent will send
|
|
|
|
|
with each copy of an email message. You can override this setting
|
|
|
|
|
for specific Postfix delivery agents. For example,
|
|
|
|
|
"uucp_destination_recipient_limit = 100" would limit the number of
|
|
|
|
|
recipients per UUCP delivery to 100. </p>
|
|
|
|
|
|
|
|
|
|
<p> If an email message exceeds the recipient limit for some
|
|
|
|
|
destination, the Postfix queue manager breaks up the list of
|
|
|
|
|
recipients into smaller lists. Postfix will attempt to send multiple
|
|
|
|
|
copies of the message in parallel. </p>
|
|
|
|
|
|
|
|
|
|
<p> IMPORTANT: Be careful when increasing the recipient limit per
|
|
|
|
|
message delivery; some smtpd(8) servers abort the connection when they
|
|
|
|
|
run out of memory or when a hard recipient limit is reached, so
|
|
|
|
|
that the message will never be delivered. </p>
|
|
|
|
|
|
|
|
|
|
<p> The smtpd_recipient_limit parameter (default: 1000) controls
|
|
|
|
|
how many recipients the Postfix smtpd(8) server will take per
|
|
|
|
|
delivery. The default limit is more than any reasonable SMTP client
|
|
|
|
|
would send. The limit exists to protect the local mail system
|
|
|
|
|
against a run-away client. </p>
|
|
|
|
|
|
|
|
|
|
<h2><a name="hammer">Tuning the frequency of deferred mail delivery attempts</a></h2>
|
|
|
|
|
|
|
|
|
|
<p> When a Postfix delivery agent (smtp(8), local(8), etc.) is
|
|
|
|
|
unable to deliver a message it may blame the message itself, or it
|
|
|
|
|
may blame the receiving party. </p>
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
|
|
|
|
<li> <p> When the delivery agent blames the message, the queue
|
|
|
|
|
manager gives the queue file a time stamp into the future, so it
|
|
|
|
|
won't be looked at for a while. By default, the amount of time to
|
|
|
|
|
cool down is the amount of time that has passed since the message
|
|
|
|
|
arrived. This results in so-called exponential backoff behavior.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<li> <p> When the delivery agent blames the receiving party (for
|
|
|
|
|
example a local recipient user, or a remote host), the queue manager
|
|
|
|
|
not only advances the queue file time stamp, but also puts the
|
|
|
|
|
receiving party on a "dead" list so that it will be skipped for
|
|
|
|
|
some amount of time. </p>
|
|
|
|
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<p> This process is governed by a bunch of little parameters. </p>
|
|
|
|
|
|
|
|
|
|
<blockquote>
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
2007-05-19 20:27:18 +04:00
|
|
|
<dt> queue_run_delay (default: 300 seconds; before Postfix 2.4:
|
|
|
|
|
1000s) </dt> <dd> How often
|
2004-04-27 08:12:43 +04:00
|
|
|
the queue manager scans the queue for deferred mail. </dd>
|
|
|
|
|
|
2007-05-19 20:27:18 +04:00
|
|
|
<dt> minimal_backoff_time (default: 300 seconds; before Postfix
|
|
|
|
|
2.4: 1000s) </dt> <dd> The
|
2004-04-27 08:12:43 +04:00
|
|
|
minimal amount of time a message won't be looked at, and the minimal
|
|
|
|
|
amount of time to stay away from a "dead" destination. </dd>
|
|
|
|
|
|
|
|
|
|
<dt> maximal_backoff_time (default: 4000 seconds) </dt> <dd> The
|
|
|
|
|
maximal amount of time a message won't be looked at after a delivery
|
|
|
|
|
failure. </dd>
|
|
|
|
|
|
|
|
|
|
<dt> maximal_queue_lifetime (default: 5 days) </dt> <dd> How long
|
|
|
|
|
a message stays in the queue before it is sent back as undeliverable.
|
|
|
|
|
Specify 0 for mail that should be returned immediately after the
|
|
|
|
|
first unsuccessful delivery attempt. </dd>
|
|
|
|
|
|
|
|
|
|
<dt> bounce_queue_lifetime (default: 5 days, available with Postfix
|
|
|
|
|
version 2.1 and later) </dt> <dd> How long a MAILER-DAEMON message
|
|
|
|
|
stays in the queue before it is considered undeliverable. Specify
|
|
|
|
|
0 for mail that should be tried only once. </dd>
|
|
|
|
|
|
|
|
|
|
<dt> qmgr_message_recipient_limit (default: 20000) </dt> <dd> The
|
|
|
|
|
size of many in-memory queue manager data structures. Among others,
|
|
|
|
|
this parameter limits the size of the short-term, in-memory list
|
|
|
|
|
of "dead" destinations. Destinations that don't fit the list are
|
|
|
|
|
not added. </dd>
|
|
|
|
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
</blockquote>
|
|
|
|
|
|
|
|
|
|
<p> IMPORTANT: If you increase the frequency of deferred mail
|
|
|
|
|
delivery attempts, or if you flush the deferred mail queue frequently,
|
|
|
|
|
then you may find that Postfix mail delivery performance actually
|
|
|
|
|
becomes worse. The symptoms are as follows: </p>
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
|
|
|
|
<li> <p> The active queue becomes saturated with mail that has
|
|
|
|
|
delivery problems. New mail enters the active queue only when
|
|
|
|
|
an old message is deferred. This is a slow process that usually
|
|
|
|
|
requires timing out one or more SMTP connections. </p>
|
|
|
|
|
|
|
|
|
|
<li> <p> All available Postfix delivery agents become occupied
|
|
|
|
|
trying to connect to unreachable sites etc. New mail has to wait
|
|
|
|
|
until a delivery agent becomes available. This is a slow process
|
|
|
|
|
that usually requires timing out one or more SMTP connections. </p>
|
|
|
|
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<p> When mail is being deferred frequently, fixing the problem is
|
|
|
|
|
always better than increasing the frequency of delivery attempts.
|
|
|
|
|
However, if you can control only the delivery attempt frequency,
|
|
|
|
|
consider using a dedicated fallback_relay "graveyard" machine for
|
2007-05-19 20:27:18 +04:00
|
|
|
bad destinations, so that these destinations do not ruin the
|
|
|
|
|
performance of normal
|
2004-04-27 08:12:43 +04:00
|
|
|
mail deliveries. </p>
|
|
|
|
|
|
|
|
|
|
<h2><a name="proc_limit">Tuning the number of Postfix processes</a></h2>
|
|
|
|
|
|
|
|
|
|
<p> The default_process_limit configuration parameter gives direct
|
|
|
|
|
control over how many daemon processes Postfix will run. As of
|
|
|
|
|
Postfix 2.0 the default limit is 100 smtp client processes, 100
|
|
|
|
|
smtp server processes, and so on. This may overwhelm systems with
|
|
|
|
|
little memory, as well as networks with low bandwidth. </p>
|
|
|
|
|
|
|
|
|
|
<p> You can change the global process limit by specifying a
|
|
|
|
|
non-default default_process_limit in the main.cf file. For example,
|
|
|
|
|
to run up to 10 smtp client processes, 10 smtp server processes,
|
|
|
|
|
and so on: </p>
|
|
|
|
|
|
|
|
|
|
<blockquote>
|
|
|
|
|
<pre>
|
|
|
|
|
/etc/postfix/main.cf:
|
|
|
|
|
default_process_limit = 10
|
|
|
|
|
</pre>
|
|
|
|
|
</blockquote>
|
|
|
|
|
|
|
|
|
|
<p> You need to execute "postfix reload" to make the change effective.
|
|
|
|
|
The limits are enforced by the Postfix master(8) daemon which does
|
|
|
|
|
not automatically read main.cf when it changes. </p>
|
|
|
|
|
|
|
|
|
|
<p> You can override the process limit for specific Postfix daemons
|
|
|
|
|
by editing the master.cf file. For example, if you do not wish to
|
|
|
|
|
receive 100 SMTP messages at the same time, but do not want to
|
|
|
|
|
change the process limits for local mail deliveries, you could
|
|
|
|
|
specify: </p>
|
|
|
|
|
|
|
|
|
|
<blockquote>
|
|
|
|
|
<pre>
|
|
|
|
|
/etc/postfix/master.cf:
|
|
|
|
|
# ====================================================================
|
|
|
|
|
# service type private unpriv chroot wakeup maxproc command + args
|
|
|
|
|
# (yes) (yes) (yes) (never) (100)
|
|
|
|
|
# ====================================================================
|
|
|
|
|
. . .
|
|
|
|
|
smtp inet n - - - 10 smtpd
|
|
|
|
|
. . .
|
|
|
|
|
</pre>
|
|
|
|
|
</blockquote>
|
|
|
|
|
|
|
|
|
|
<h2><a name="file_limit">Tuning the number of open files or sockets</a></h2>
|
|
|
|
|
|
|
|
|
|
<p> When Postfix opens too many files or sockets, processes will
|
|
|
|
|
abort with fatal errors, and the system may log "file table full"
|
|
|
|
|
errors. </p>
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
2007-05-19 20:27:18 +04:00
|
|
|
<li> <p> Depending on your Postfix and operating system versions
|
|
|
|
|
you may need to recompile Postfix if you need more than 1024 file
|
|
|
|
|
descriptors per process: </p>
|
|
|
|
|
|
|
|
|
|
<ul> <li> <p> No recompilation is needed for Postfix version 2.4
|
|
|
|
|
and later, when it was compiled for systems that support BSD kqueue(2)
|
|
|
|
|
(FreeBSD 4.1, NetBSD 2.0, OpenBSD 2.9), Solaris 8 /dev/poll, or
|
|
|
|
|
Linux 2.6 epoll(4). </p>
|
|
|
|
|
|
|
|
|
|
<li> <p> Otherwise, Postfix needs to be recompiled to override the
|
|
|
|
|
default FD_SETSIZE value. </p>
|
|
|
|
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
2004-04-27 08:12:43 +04:00
|
|
|
<li> <p> Reduce the number of processes as described under "<a
|
|
|
|
|
href="#proc_limit">Tuning the number of Postfix processes</a>" above.
|
|
|
|
|
Fewer processes need fewer open files and sockets. </p>
|
|
|
|
|
|
|
|
|
|
<li> <p> Configure the kernel for more open files and sockets.
|
|
|
|
|
The details are extremely system dependent and change with the
|
|
|
|
|
operating system version. Be sure to verify the following information
|
|
|
|
|
with your system tuning guide: </p>
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
|
|
|
|
<li> <p> Some FreeBSD kernel parameters can be specified in
|
2007-05-19 20:27:18 +04:00
|
|
|
/boot/loader.conf, and some can be specified in /etc/sysctl.conf
|
|
|
|
|
or changed with sysctl commands.
|
2004-04-27 08:12:43 +04:00
|
|
|
Which is which depends on the version.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<pre>
|
|
|
|
|
kern.ipc.maxsockets="5000"
|
|
|
|
|
kern.ipc.nmbclusters="65536"
|
|
|
|
|
kern.maxproc="2048"
|
|
|
|
|
kern.maxfiles="16384"
|
|
|
|
|
kern.maxfilesperproc="16384"
|
|
|
|
|
</pre>
|
|
|
|
|
|
|
|
|
|
<li> <p> Linux kernel parameters can be specified in /etc/sysctl.conf
|
2007-05-19 20:27:18 +04:00
|
|
|
or changed with sysctl commands: </p>
|
2004-04-27 08:12:43 +04:00
|
|
|
|
|
|
|
|
<pre>
|
|
|
|
|
fs.file-max=16384
|
|
|
|
|
kernel.threads-max=2048
|
|
|
|
|
</pre>
|
|
|
|
|
|
|
|
|
|
<li> <p> Solaris kernel parameters can be specified in /etc/system,
|
|
|
|
|
as described in the <a
|
2007-05-19 20:27:18 +04:00
|
|
|
href="http://www.science.uva.nl/pub/solaris/solaris2.html#q3.48">Solaris
|
2004-04-27 08:12:43 +04:00
|
|
|
FAQ</a> entry titled "How can I increase the number of file
|
|
|
|
|
descriptors per process?" </p>
|
|
|
|
|
|
|
|
|
|
<pre>
|
|
|
|
|
* set hard limit on file descriptors
|
|
|
|
|
set rlim_fd_max = 4096
|
|
|
|
|
* set soft limit on file descriptors
|
|
|
|
|
set rlim_fd_cur = 1024
|
|
|
|
|
</pre>
|
|
|
|
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
</body>
|
|
|
|
|
|
|
|
|
|
</html>
|
