Gecko [ 122.154.134.11 ]

Name	Size	Permission
AAAREADME	2.7 KB	-rw-r--r--
ADDRESS_CLASS_README	9.33 KB	-rw-r--r--
ADDRESS_REWRITING_README	42.68 KB	-rw-r--r--
ADDRESS_VERIFICATION_README	19.46 KB	-rw-r--r--
BACKSCATTER_README	12.3 KB	-rw-r--r--
BASIC_CONFIGURATION_README	20.73 KB	-rw-r--r--
BUILTIN_FILTER_README	13.94 KB	-rw-r--r--
CDB_README	2.69 KB	-rw-r--r--
CONNECTION_CACHE_README	8.96 KB	-rw-r--r--
CONTENT_INSPECTION_README	3.29 KB	-rw-r--r--
DATABASE_README	13.25 KB	-rw-r--r--
DB_README	6.9 KB	-rw-r--r--
DEBUG_README	17.71 KB	-rw-r--r--
DSN_README	4.33 KB	-rw-r--r--
ETRN_README	11.4 KB	-rw-r--r--
FILTER_README	27.04 KB	-rw-r--r--
INSTALL	32.72 KB	-rw-r--r--
IPV6_README	11.73 KB	-rw-r--r--
LDAP_README	19.83 KB	-rw-r--r--
LINUX_README	1.64 KB	-rw-r--r--
LOCAL_RECIPIENT_README	5.65 KB	-rw-r--r--
MAILDROP_README	5.16 KB	-rw-r--r--
MILTER_README	36.6 KB	-rw-r--r--
MULTI_INSTANCE_README	42.4 KB	-rw-r--r--
MYSQL_README	4.31 KB	-rw-r--r--
NFS_README	4.73 KB	-rw-r--r--
OVERVIEW	18.57 KB	-rw-r--r--
PACKAGE_README	5.45 KB	-rw-r--r--
PCRE_README	2.87 KB	-rw-r--r--
PGSQL_README	4.4 KB	-rw-r--r--
QSHAPE_README	36.13 KB	-rw-r--r--
RELEASE_NOTES	12.37 KB	-rw-r--r--
RESTRICTION_CLASS_README	6.71 KB	-rw-r--r--
SASL_README	23.29 KB	-rw-r--r--
SCHEDULER_README	65.06 KB	-rw-r--r--
SMTPD_ACCESS_README	15.41 KB	-rw-r--r--
SMTPD_POLICY_README	19.37 KB	-rw-r--r--
SMTPD_PROXY_README	10.47 KB	-rw-r--r--
STANDARD_CONFIGURATION_README	25.24 KB	-rw-r--r--
STRESS_README	19.62 KB	-rw-r--r--
TLS_LEGACY_README	51.46 KB	-rw-r--r--
TLS_README	96.1 KB	-rw-r--r--
TUNING_README	23.76 KB	-rw-r--r--
ULTRIX_README	1.96 KB	-rw-r--r--
UUCP_README	5.14 KB	-rw-r--r--
VERP_README	7 KB	-rw-r--r--
VIRTUAL_README	23.29 KB	-rw-r--r--
XCLIENT_README	9.39 KB	-rw-r--r--
XFORWARD_README	8.28 KB	-rw-r--r--

Code Editor : TUNING_README

PPoossttffiixx PPeerrffoorrmmaannccee TTuunniinngg

-------------------------------------------------------------------------------

PPuurrppoossee ooff PPoossttffiixx ppeerrffoorrmmaannccee ttuunniinngg

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.

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.

Topics on mail receiving performance:

* General mail receiving performance tips
  * Doing more work with your SMTP server processes
  * Slowing down SMTP clients that make many errors
  * Measures against clients that make too many connections

Topics on mail delivery performance:

* General mail delivery performance tips
  * Tuning the frequency of deferred mail delivery attempts
  * Tuning the number of simultaneous deliveries
  * Tuning the number of recipients per delivery

Other Postfix performance tuning topics:

* Tuning the number of Postfix processes
  * Tuning the number of processes on the system
  * Tuning the number of open files or sockets

The following tools can be used to measure mail system performance under
artificial loads. They are normally not installed with Postfix.

* smtp-source, SMTP/LMTP message generator
  * smtp-sink, SMTP/LMTP message dump
  * qmqp-source, QMQP message generator
  * qmqp-sink, QMQP message dump

GGeenneerraall mmaaiill rreecceeiivviinngg ppeerrffoorrmmaannccee ttiippss

* Read and understand the maildrop queue, incoming queue, and active queue
    discussions in the QSHAPE_README document.

* 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.

* 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.

When Postfix responds slowly to SMTP clients:

* Look for obvious signs of trouble as described in the DEBUG_README
    document, and eliminate those problems first.

* Turn off your header_checks and body_checks patterns and see if the problem
    goes away.

* Turn off chroot operation as described in the DEBUG_README document and see
    if the problem goes away.

* 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.

* 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 "Tuning the number of Postfix processes".

DDooiinngg mmoorree wwoorrkk wwiitthh yyoouurr SSMMTTPP sseerrvveerr pprroocceesssseess

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.

You can speed up the handling of smtpd(8) server error replies by turning off
the delay:

/etc/postfix/main.cf:
        # Not needed with Postfix 2.1
        smtpd_error_sleep_time = 0

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.

SSlloowwiinngg ddoowwnn SSMMTTPP cclliieennttss tthhaatt mmaakkee mmaannyy eerrrroorrss

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 access restrictions, or when some other error happens.

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.

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.

Postfix version 2.1 and later:

* 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).

* When the error count reaches $smtpd_hard_error_limit (default: 20) the
    Postfix smtpd(8) server breaks the connection.

Postfix version 2.0 and earlier:

* 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).

* 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.

* When the error count reaches $smtpd_hard_error_limit (default: 20) the
    Postfix smtpd(8) server breaks the connection.

MMeeaassuurreess aaggaaiinnsstt cclliieennttss tthhaatt mmaakkee ttoooo mmaannyy ccoonnnneeccttiioonnss

Note: these features use the Postfix anvil(8) service, introduced with Postfix
version 2.2.

The Postfix smtpd(8) server can limit the number of simultaneous connections
from the same SMTP client, as well as the connection rate and the rate of
certain SMTP commands from the same client. These statistics are maintained by
the anvil(8) server (translation: if anvil(8) breaks, then connection limits
stop working).

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.

smtpd_client_connection_count_limit (default: 50)
        The maximum number of connections that an SMTP client may make
        simultaneously.
    smtpd_client_connection_rate_limit (default: no limit)
        The maximum number of connections that an SMTP client may make in the
        time interval specified with anvil_rate_time_unit (default: 60s).
    smtpd_client_message_rate_limit (default: no limit)
        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).
    smtpd_client_recipient_rate_limit (default: no limit)
        The maximum number of recipient addresses that an SMTP client may
        specify in the time interval specified with anvil_rate_time_unit
        (default: 60s).
    smtpd_client_new_tls_session_rate_limit (default: no limit)
        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).
    smtpd_client_event_limit_exceptions (default: $mynetworks)
        SMTP clients that are excluded from connection and rate limits
        specified above.

GGeenneerraall mmaaiill ddeelliivveerryy ppeerrffoorrmmaannccee ttiippss

* Read and understand the maildrop queue, incoming queue, active queue and
    deferred queue discussions in the QSHAPE_README document.

* In case of slow delivery, run the qshape tool as described in the
    QSHAPE_README document.

* Submit multiple recipients per message instead of submitting messages with
    only a few recipients.

* Submit mail via SMTP instead of /usr/sbin/sendmail. You may have to adjust
    the smtpd_recipient_limit parameter setting.

* 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.

* Reduce the smtp_connect_timeout and smtp_helo_timeout values so that
    Postfix does not waste lots of time connecting to non-responding remote
    SMTP servers.

* Use a dedicated mail delivery transport for problematic destinations, with
    reduced timeouts and with adjusted concurrency. See "Tuning the number of
    simultaneous deliveries" below.

* 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 "Tuning the frequency of deferred mail delivery
    attempts" below.

* 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.

* 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.

TTuunniinngg tthhee nnuummbbeerr ooff ssiimmuullttaanneeoouuss ddeelliivveerriieess

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.

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.

* 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.

* 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".

Examples of transport specific concurrency limits are:

* 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 at the same time.

* 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.

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.

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.

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.

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.

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.

TTuunniinngg tthhee nnuummbbeerr ooff rreecciippiieennttss ppeerr ddeelliivveerryy

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.

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.

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.

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.

TTuunniinngg tthhee ffrreeqquueennccyy ooff ddeeffeerrrreedd mmaaiill ddeelliivveerryy aatttteemmppttss

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.

* 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.

* 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.

This process is governed by a bunch of little parameters.

queue_run_delay (default: 300 seconds; before Postfix 2.4: 1000s)
        How often the queue manager scans the queue for deferred mail.
    minimal_backoff_time (default: 300 seconds; before Postfix 2.4: 1000s)
        The minimal amount of time a message won't be looked at, and the
        minimal amount of time to stay away from a "dead" destination.
    maximal_backoff_time (default: 4000 seconds)
        The maximal amount of time a message won't be looked at after a
        delivery failure.
    maximal_queue_lifetime (default: 5 days)
        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.
    bounce_queue_lifetime (default: 5 days, available with Postfix version 2.1
    and later)
        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.
    qmgr_message_recipient_limit (default: 20000)
        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.

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:

* 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.

* 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.

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 bad destinations, so that these destinations do not
ruin the performance of normal mail deliveries.

TTuunniinngg tthhee nnuummbbeerr ooff PPoossttffiixx pprroocceesssseess

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.

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:

/etc/postfix/main.cf:
        default_process_limit = 10

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.

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:

/etc/postfix/master.cf:
        # ====================================================================
        # service type  private unpriv  chroot  wakeup  maxproc command + args
        #               (yes)   (yes)   (yes)   (never) (100)
        # ====================================================================
        . . .
        smtp      inet  n       -       -       -       10      smtpd
        . . .

TTuunniinngg tthhee nnuummbbeerr ooff pprroocceesssseess oonn tthhee ssyysstteemm

* MacOS X will run out of process slots when you increase Postfix process
    limits. The following works with OSX 10.4 and OSX 10.5.

MacOS X kernel parameters can be specified in /etc/sysctl.conf.

/etc/sysctl.conf:
        kern.maxproc=2048
        kern.maxprocperuid=2048

Unfortunately these can't simply be set on the fly with "sysctl -w". You
    also have to set the following in /etc/launchd.conf so that the root user
    after boot will have the right process limit (2048). Otherwise you have to
    always run ulimit -u 2048 as root, then start a user shell, and then start
    processes for things to take effect.

/etc/launchd.conf:
        limit maxproc 2048

Once these are in place, reboot the system. After that, the limits will
    stay in place.

TTuunniinngg tthhee nnuummbbeerr ooff ooppeenn ffiilleess oorr ssoocckkeettss

When Postfix opens too many files or sockets, processes will abort with fatal
errors, and the system may log "file table full" errors.

* Depending on your Postfix and operating system versions you may need to
    recompile Postfix if you need more than 1024 file descriptors per process:

o 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).

o Otherwise, Postfix needs to be recompiled to override the default
        FD_SETSIZE value.

* Reduce the number of processes as described under "Tuning the number of
    Postfix processes" above. Fewer processes need fewer open files and
    sockets.

* 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:

o Some FreeBSD kernel parameters can be specified in /boot/loader.conf,
        and some can be specified in /etc/sysctl.conf or changed with sysctl
        commands. Which is which depends on the version.

kern.ipc.maxsockets="5000"
        kern.ipc.nmbclusters="65536"
        kern.maxproc="2048"
        kern.maxfiles="16384"
        kern.maxfilesperproc="16384"

o Linux kernel parameters can be specified in /etc/sysctl.conf or changed
        with sysctl commands:

fs.file-max=16384
        kernel.threads-max=2048

o Solaris kernel parameters can be specified in /etc/system, as described
        in the Solaris FAQ entry titled "How can I increase the number of file
        descriptors per process?"

* set hard limit on file descriptors
        set rlim_fd_max = 4096
        * set soft limit on file descriptors
        set rlim_fd_cur = 1024

${this.title}

Code Editor : TUNING_README