postfix-master/TUNING_README.html

   1 <!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN"
   2         "http://www.w3.org/TR/html4/loose.dtd">
   3
   4 <html>
   5
   6 <head>
   7
   8 <title>Postfix Performance Tuning</title>
   9
  10 <meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
  11
  12 </head>
  13
  14 <body>
  15
  16 <h1><img src="postfix-logo.jpg" width="203" height="98" alt="">
  17 Postfix Performance Tuning</h1>
  18
  19 <hr>
  20
  21 <h2>Purpose of Postfix performance tuning </h2>
  22
  23 <p> The hints and tips in this document help you improve the
  24 performance of Postfix systems that already work.  If your Postfix
  25 system is unable to receive or deliver mail, then you need to solve
  26 those problems first, using the <a href="DEBUG_README.html">DEBUG_README</a> document as guidance.
  27
  28 <p> For tuning external content filter performance, first read the
  29 respective information in the <a href="FILTER_README.html">FILTER_README</a> and <a href="SMTPD_PROXY_README.html">SMTPD_PROXY_README</a>
  30 documents. Then make sure to avoid latency in the content filter
  31 code. As much as possible avoid performing queries against external
  32 data sources with a high or highly variable delay. Your content
  33 filter will run with a small concurrency to avoid CPU/memory
  34 starvation, and if any latency creeps in, content filter throughput
  35 will suffer. High volume environments should avoid RBL lookups,
  36 complex database queries and so on. </p>
  37
  38 <p>Topics on mail receiving performance: </p>
  39
  40 <ul>
  41
  42 <li> <a href="#server_tips">General mail receiving performance tips</a>
  43
  44 <li> <a href="#speedup">Doing more work with your SMTP server processes</a>
  45
  46 <li> <a href="#slowdown">Slowing down SMTP clients that make many errors</a>
  47
  48 <li> <a href="#conn_limit">Measures against clients that make too many connections</a>
  49
  50 </ul>
  51
  52 <p>Topics on mail delivery performance: </p>
  53
  54 <ul>
  55
  56 <li> <a href="#mailing_tips">General mail delivery performance tips</a>
  57
  58 <li> <a href="#hammer">Tuning the frequency of deferred mail delivery attempts</a>
  59
  60 <li> <a href="#rope">Tuning the number of simultaneous deliveries</a>
  61
  62 <li> <a href="#rcpts">Tuning the number of recipients per delivery</a>
  63
  64 </ul>
  65
  66 <p>Other Postfix performance tuning topics:  </p>
  67
  68 <ul>
  69
  70 <li> <a href="#proc_limit">Tuning the number of Postfix processes</a>
  71
  72 <li> <a href="#proc_sys">Tuning the number of processes on the system</a>
  73
  74 <li> <a href="#file_limit">Tuning the number of open files or
  75 sockets</a>
  76
  77 </ul>
  78
  79 <p> The following tools can be used to measure mail system performance
  80 under artificial loads. They are normally not installed with Postfix.
  81 </p>
  82
  83 <ul>
  84
  85 <li> <a href="smtp-source.1.html">smtp-source, SMTP/LMTP message
  86 generator</a>
  87
  88 <li> <a href="smtp-sink.1.html">smtp-sink, SMTP/LMTP message dump
  89 </a>
  90
  91 <li> <a href="qmqp-source.1.html">qmqp-source, QMQP message generator
  92 </a>
  93
  94 <li> <a href="qmqp-sink.1.html">qmqp-sink, QMQP message dump </a>
  95
  96 </ul>
  97
  98 <h2><a name="server_tips">General mail receiving performance
  99 tips</a></h2>
 100
 101 <ul>
 102
 103 <li> <p> Read and understand the <a href="QSHAPE_README.html#maildrop_queue">maildrop queue</a>, <a href="QSHAPE_README.html#incoming_queue">incoming queue</a>,
 104 and <a href="QSHAPE_README.html#active_queue">active queue</a> discussions in the <a href="QSHAPE_README.html">QSHAPE_README</a> document. </p>
 105
 106 <li> <p> Run a local name server to reduce slow-down due to DNS
 107 lookups. If you run multiple Postfix systems, point each local name
 108 server to a shared forwarding server to reduce the number of lookups
 109 across the upstream network link. </p>
 110
 111 <li> <p> Eliminate unnecessary LDAP lookups, by specifying a domain
 112 filter. This eliminates lookups for addresses in remote domains,
 113 and eliminates lookups of partial addresses.  See <a href="ldap_table.5.html">ldap_table(5)</a> for
 114 details. </p>
 115
 116 </ul>
 117
 118 <p> When Postfix responds slowly to SMTP clients: </p>
 119
 120 <ul>
 121
 122 <li> <p> <a href="DEBUG_README.html#logging">Look for obvious signs
 123 of trouble</a> as described in the DEBUG_README document, and
 124 eliminate those problems first. </p>
 125
 126 <li> <p> Turn off your <a href="postconf.5.html#header_checks">header_checks</a> and <a href="postconf.5.html#body_checks">body_checks</a> patterns and
 127 see if the problem goes away. </p>
 128
 129 <li> <p> <a href="DEBUG_README.html#no_chroot">Turn off chroot
 130 operation</a> as described in the DEBUG_README document and see
 131 if the problem goes away. </p>
 132
 133 <li> <p> If Postfix logs the SMTP client as "unknown" then you have
 134 a name service problem: the name server is bad, or the resolv.conf
 135 file contains bad information, or some packet filter is blocking
 136 the DNS requests or replies.  </p>
 137
 138 <li> <p> If the number of <a href="smtpd.8.html">smtpd(8)</a> processes has reached the process
 139 limit as specified in <a href="master.5.html">master.cf</a>, new SMTP clients must wait until
 140 a process becomes available.  Increase the number of processes if
 141 memory permits. See the instructions given under "<a
 142 href="#proc_limit">Tuning the number of Postfix processes</a>".
 143 </p>
 144
 145 </ul>
 146
 147 <h2><a name="speedup">Doing more work with your SMTP server
 148 processes</a></h2>
 149
 150 <p> With Postfix versions 2.0 and earlier, the <a href="smtpd.8.html">smtpd(8)</a> server
 151 pauses before reporting an error to an SMTP client. The idea is
 152 called tar pitting.  However, these delays also slow down Postfix.
 153 When the <a href="smtpd.8.html">smtpd(8)</a> server replies slowly, sessions take more time,
 154 so that more <a href="smtpd.8.html">smtpd(8)</a> server processes are needed to handle the
 155 load. When your Postfix <a href="smtpd.8.html">smtpd(8)</a> server process limit is reached,
 156 new clients must wait until a server process becomes available.
 157 This means that all clients experience poor performance.  </p>
 158
 159 <p> You can speed up the handling of <a href="smtpd.8.html">smtpd(8)</a> server error replies
 160 by turning off the delay: </p>
 161
 162 <blockquote>
 163 <pre>
 164 /etc/postfix/<a href="postconf.5.html">main.cf</a>:
 165     # Not needed with Postfix 2.1
 166     <a href="postconf.5.html#smtpd_error_sleep_time">smtpd_error_sleep_time</a> = 0
 167 </pre>
 168 </blockquote>
 169
 170 <p> With the above setting, Postfix 2.0 and earlier can serve more
 171 SMTP clients with the same number SMTP server processes. The next
 172 section describes how Postfix deals with clients that make a large
 173 number of errors.  </p>
 174
 175 <h2><a name="slowdown"> Slowing down SMTP clients that make many errors</a></h2>
 176
 177 <p> The Postfix <a href="smtpd.8.html">smtpd(8)</a> server maintains a per-session error count.
 178 The error count is reset when a message is transferred successfully,
 179 and is incremented when a client request is unrecognized or
 180 unimplemented, when a client request violates <a
 181 href="SMTPD_ACCESS_README.html">access restrictions</a>, or when
 182 some other error happens.  </p>
 183
 184 <p> As the per-session error count increases, the <a href="smtpd.8.html">smtpd(8)</a> server
 185 changes behavior and begins to insert delays into the responses.
 186 The idea is to slow down a run-away client in order to limit resource
 187 usage.  The behavior is Postfix version dependent. </p>
 188
 189 <p> IMPORTANT: These delays slow down Postfix, too. When too much
 190 delay is configured, the number of simultaneous SMTP sessions will
 191 increase until it reaches the <a href="smtpd.8.html">smtpd(8)</a> server process limit, and new
 192 SMTP clients must wait until an <a href="smtpd.8.html">smtpd(8)</a> server process becomes available.
 193 </p>
 194
 195 <p> Postfix version 2.1 and later:</p>
 196
 197 <ul>
 198
 199 <li> <p> When the error count reaches $<a href="postconf.5.html#smtpd_soft_error_limit">smtpd_soft_error_limit</a>
 200 (default: 10), the Postfix <a href="smtpd.8.html">smtpd(8)</a> server delays all non-error and
 201 error responses by $<a href="postconf.5.html#smtpd_error_sleep_time">smtpd_error_sleep_time</a> seconds (default: 1
 202 second).  </p>
 203
 204 <li><p>When the error count reaches $<a href="postconf.5.html#smtpd_hard_error_limit">smtpd_hard_error_limit</a>
 205 (default: 20) the Postfix <a href="smtpd.8.html">smtpd(8)</a> server breaks the connection. </p>
 206
 207 </ul>
 208
 209 <p> Postfix version 2.0 and earlier:</p>
 210
 211 <ul>
 212
 213 <li> <p> When the error count is less than $<a href="postconf.5.html#smtpd_soft_error_limit">smtpd_soft_error_limit</a>
 214 (default: 10) the Postfix <a href="smtpd.8.html">smtpd(8)</a> server delays all error replies by
 215 $<a href="postconf.5.html#smtpd_error_sleep_time">smtpd_error_sleep_time</a> (1 second with Postfix 2.0, 5 seconds with
 216 Postfix 1.1 and earlier). </p>
 217
 218 <li> <p> When the error count reaches $<a href="postconf.5.html#smtpd_soft_error_limit">smtpd_soft_error_limit</a>,
 219 the Postfix <a href="smtpd.8.html">smtpd(8)</a> server delays all responses by "error count"
 220 seconds or $<a href="postconf.5.html#smtpd_error_sleep_time">smtpd_error_sleep_time</a>, whichever is more.  </p>
 221
 222 <li><p>When the error count reaches $<a href="postconf.5.html#smtpd_hard_error_limit">smtpd_hard_error_limit</a>
 223 (default: 20) the Postfix <a href="smtpd.8.html">smtpd(8)</a> server breaks the connection. </p>
 224
 225 </ul>
 226
 227 <h2><a name="conn_limit">Measures against clients that make too many connections</a></h2>
 228
 229 <p> Note: these features use the Postfix <a href="anvil.8.html">anvil(8)</a> service, introduced
 230 with Postfix version 2.2. </p>
 231
 232 <p> The Postfix <a href="smtpd.8.html">smtpd(8)</a> server can limit the number of simultaneous
 233 connections from the same SMTP client, as well as the connection
 234 rate and the rate of certain SMTP commands from the same client.
 235 These statistics are maintained by the <a href="anvil.8.html">anvil(8)</a> server (translation:
 236 if <a href="anvil.8.html">anvil(8)</a> breaks, then connection limits stop working). </p>
 237
 238 <p> IMPORTANT: These limits must not be used to regulate legitimate
 239 traffic: mail will suffer grotesque delays if you do so.  The limits
 240 are designed to protect the <a href="smtpd.8.html">smtpd(8)</a> server against abuse by
 241 out-of-control clients.  </p>
 242
 243 <blockquote>
 244
 245 <dl>
 246
 247 <dt> <a href="postconf.5.html#smtpd_client_connection_count_limit">smtpd_client_connection_count_limit</a> (default: 50) </dt> <dd>
 248 The maximum number of connections that an SMTP client may make
 249 simultaneously. </dd>
 250
 251 <dt> <a href="postconf.5.html#smtpd_client_connection_rate_limit">smtpd_client_connection_rate_limit</a> (default: no limit) </dt>
 252 <dd> The maximum number of connections that an SMTP client may make
 253 in the time interval specified with <a href="postconf.5.html#anvil_rate_time_unit">anvil_rate_time_unit</a> (default:
 254 60s).  </dd>
 255
 256 <dt> <a href="postconf.5.html#smtpd_client_message_rate_limit">smtpd_client_message_rate_limit</a> (default: no limit) </dt> <dd>
 257 The maximum number of message delivery requests that an SMTP client
 258 may make in the time interval specified with <a href="postconf.5.html#anvil_rate_time_unit">anvil_rate_time_unit</a>
 259 (default: 60s). </dd>
 260
 261 <dt> <a href="postconf.5.html#smtpd_client_recipient_rate_limit">smtpd_client_recipient_rate_limit</a> (default: no limit) </dt>
 262 <dd> The maximum number of recipient addresses that an SMTP client
 263 may specify in the time interval specified with <a href="postconf.5.html#anvil_rate_time_unit">anvil_rate_time_unit</a>
 264 (default: 60s). </dd>
 265
 266 <dt> <a href="postconf.5.html#smtpd_client_new_tls_session_rate_limit">smtpd_client_new_tls_session_rate_limit</a> (default: no limit)
 267 </dt> <dd> The maximum number of new TLS sessions (without using
 268 the TLS session cache) that an SMTP client may negotiate in the
 269 time interval specified with <a href="postconf.5.html#anvil_rate_time_unit">anvil_rate_time_unit</a> (default: 60s).
 270 </dd>
 271
 272 <dt> <a href="postconf.5.html#smtpd_client_event_limit_exceptions">smtpd_client_event_limit_exceptions</a> (default: $<a href="postconf.5.html#mynetworks">mynetworks</a>)
 273 </dt> <dd> SMTP clients that are excluded from connection and rate
 274 limits specified above. </dd>
 275
 276 </dl>
 277
 278 </blockquote>
 279
 280 <h2><a name="mailing_tips">General mail delivery performance tips</a></h2>
 281
 282 <ul>
 283
 284 <li> <p> Read and understand the <a href="QSHAPE_README.html#maildrop_queue">maildrop queue</a>, <a href="QSHAPE_README.html#incoming_queue">incoming queue</a>,
 285 <a href="QSHAPE_README.html#active_queue">active queue</a> and <a href="QSHAPE_README.html#deferred_queue">deferred queue</a> discussions in the <a href="QSHAPE_README.html">QSHAPE_README</a>
 286 document. </p>
 287
 288 <li> <p> In case of slow delivery, run the qshape tool as described
 289 in the <a href="QSHAPE_README.html">QSHAPE_README</a> document. </p>
 290
 291 <li> <p> Submit multiple recipients per message instead of submitting
 292 messages with only a few recipients. </p>
 293
 294 <li> <p> Submit mail via SMTP instead of /usr/sbin/sendmail.  You
 295 may have to adjust the <a href="postconf.5.html#smtpd_recipient_limit">smtpd_recipient_limit</a> parameter setting.
 296 </p>
 297
 298 <li> <p> Don't overwhelm the disk with mail submissions.  Optimize
 299 the mail submission rate by tuning the number of parallel submissions
 300 and/or by tuning the Postfix <a href="postconf.5.html#in_flow_delay">in_flow_delay</a> parameter setting.  </p>
 301
 302 <li> <p> Run a local name server to reduce slow-down due to DNS
 303 lookups. If you run multiple Postfix systems, point each local name
 304 server to a shared forwarding server to reduce the number of lookups
 305 across the upstream network link. </p>
 306
 307 <li> <p> Reduce the <a href="postconf.5.html#smtp_connect_timeout">smtp_connect_timeout</a> and <a href="postconf.5.html#smtp_helo_timeout">smtp_helo_timeout</a>
 308 values so that Postfix does not waste lots of time connecting
 309 to non-responding remote SMTP servers. </p>
 310
 311 <li> <p> Use a dedicated mail delivery transport for problematic
 312 destinations, with reduced timeouts and with adjusted concurrency.
 313 See "<a href="#rope">Tuning the number of simultaneous deliveries</a>"
 314 below.
 315 </p>
 316
 317 <li> <p> Use a <a href="postconf.5.html#fallback_relay">fallback_relay</a> host for mail that cannot be delivered
 318 upon the first attempt. This "graveyard" machine can use shorter
 319 retry times for difficult to reach destinations. See "<a
 320 href="#hammer">Tuning the frequency of deferred mail delivery
 321 attempts</a>" below. </p>
 322
 323 <li> <p> Speed up disk updates with a large (64MB) persistent write
 324 cache. This allows disk updates to be sorted for optimal access
 325 speed without compromising file system integrity when the system
 326 crashes. </p>
 327
 328 <li> <p> Use a solid-state disk (a persistent RAM disk). This
 329 is an expensive solution that should be used in combination
 330 with short SMTP timeouts and a <a href="postconf.5.html#fallback_relay">fallback_relay</a> "graveyard"
 331 machine that delivers mail for problem destinations.  </p>
 332
 333 </ul>
 334
 335 <h2><a name="rope">Tuning the number of simultaneous deliveries</a></h2>
 336
 337 <p> Although Postfix can be configured to run 1000 SMTP client
 338 processes at the same time, it is rarely desirable that it makes
 339 1000 simultaneous connections to the same remote system. For this
 340 reason, Postfix has safety mechanisms in place to avoid this
 341 so-called "thundering herd" problem. </p>
 342
 343 <p> The Postfix queue manager implements the analog of the TCP slow
 344 start flow control strategy: when delivering to a site, send a
 345 small number of messages first, then increase the concurrency as
 346 long as all goes well; reduce concurrency in the face of congestion.
 347 </p>
 348
 349 <ul>
 350
 351 <li> <p> The <a href="postconf.5.html#initial_destination_concurrency">initial_destination_concurrency</a> parameter (default: 5)
 352 controls how many messages are initially sent to the same destination
 353 before adapting delivery concurrency. Of course, this setting is
 354 effective only as long as it does not exceed the process limit and
 355 the destination concurrency limit for the specific mail transport
 356 channel. </p>
 357
 358 <li> <p> The <a href="postconf.5.html#default_destination_concurrency_limit">default_destination_concurrency_limit</a> parameter (default:
 359 20) controls how many messages may be sent to the same destination
 360 simultaneously. You can override this setting for specific message
 361 delivery transports by taking the name of the <a href="master.5.html">master.cf</a> entry
 362 and appending "_destination_concurrency_limit". </p>
 363
 364 </ul>
 365
 366 <p> Examples of transport specific concurrency limits are: </p>
 367
 368 <ul>
 369
 370 <li> <p> The <a href="postconf.5.html#local_destination_concurrency_limit">local_destination_concurrency_limit</a> parameter (default:
 371 2) controls how many messages are delivered simultaneously to the
 372 same local recipient. The recommended limit is low because delivery
 373 to the same mailbox must happen sequentially, so massive parallelism
 374 is not useful. Another good reason to limit delivery concurrency
 375 to the same recipient: if the recipient has an expensive shell
 376 command in her .forward file, or if the recipient is a mailing list
 377 manager, you don't want to run too many instances of those processes
 378 at the same time.  </p>
 379
 380 <li> <p> The default <a href="postconf.5.html#smtp_destination_concurrency_limit">smtp_destination_concurrency_limit</a> of 20 seems
 381 enough to noticeably load a system without bringing it to its knees.
 382 Be careful when changing this to a much larger number. </p>
 383
 384 </ul>
 385
 386 <p> The above default values of the concurrency limits work well
 387 in a broad range of situations. Knee-jerk changes to these parameters
 388 in the face of congestion can actually make problems worse.
 389 Specifically, large destination concurrencies should never be the
 390 default. They should be used only for transports that deliver mail
 391 to a small number of high volume domains.  </p>
 392
 393 <p> A common situation where high concurrency is called for is on
 394 gateways relaying a high volume of mail from between the Internet
 395 and an intranet mail environment. Approximately half the mail
 396 (assuming equal volumes inbound and outbound) will be destined
 397 for the internal mail hubs.  Since the internal mail hubs will be
 398 receiving all external mail exclusively from the gateway, it is
 399 reasonable to configure the gateway to make greater demands on the
 400 capacity of the internal SMTP servers. </p>
 401
 402 <p> The tuning of the inbound concurrency limits need not be trial
 403 and error. A high volume capable mailhub should be able to easily
 404 handle 50 or 100 (rather than the default 20) simultaneous connections,
 405 especially if the gateway forwards to multiple MX hosts. When all
 406 MX hosts are up and accepting connections in a timely fashion,
 407 throughput will be high.  If any MX host is down and completely
 408 unresponsive, the average connection latency rises to at least 1/N
 409 * $smtp_connection_timeout, if there are N MX hosts. This limits
 410 throughput to at most the destination concurrency * N /
 411 $smtp_connection_timeout. </p>
 412
 413 <p> For example, with a destination concurrency of 100 and 2 MX
 414 hosts, each host will handle up to 50 simultaneous connections. If
 415 one MX host is down and the default SMTP connection timeout is 30s,
 416 the throughput limit is 100 * 2 / 30 ~= 6 messages per second. This
 417 suggests that high volume destinations with good connectivity and
 418 multiple MX hosts need a lower connection timeout, values as low
 419 as 5s or even 1s can be used to prevent congestion when one or
 420 more, but not all MX hosts are down. </p>
 421
 422 <p> If necessary, set a higher transport_destination_concurrency_limit
 423 (in <a href="postconf.5.html">main.cf</a> since this is a queue manager parameter) and a lower
 424 smtp_connection_timeout (with a "-o" override in <a href="master.5.html">master.cf</a> since
 425 this parameter has no per-transport name) for the relay transport
 426 and any transports dedicated for specific high volume destinations.
 427 </p>
 428
 429 <h2><a name="rcpts">Tuning the number of recipients per delivery</a></h2>
 430
 431 <p> The <a href="postconf.5.html#default_destination_recipient_limit">default_destination_recipient_limit</a> parameter (default:
 432 50) controls how many recipients a Postfix delivery agent will send
 433 with each copy of an email message.  You can override this setting
 434 for specific Postfix delivery agents.  For example,
 435 "uucp_destination_recipient_limit = 100" would limit the number of
 436 recipients per UUCP delivery to 100. </p>
 437
 438 <p> If an email message exceeds the recipient limit for some
 439 destination, the Postfix queue manager breaks up the list of
 440 recipients into smaller lists. Postfix will attempt to send multiple
 441 copies of the message in parallel. </p>
 442
 443 <p> IMPORTANT: Be careful when increasing the recipient limit per
 444 message delivery; some <a href="smtpd.8.html">smtpd(8)</a> servers abort the connection when they
 445 run out of memory or when a hard recipient limit is reached, so
 446 that the message will never be delivered. </p>
 447
 448 <p> The <a href="postconf.5.html#smtpd_recipient_limit">smtpd_recipient_limit</a> parameter (default: 1000) controls
 449 how many recipients the Postfix <a href="smtpd.8.html">smtpd(8)</a> server will take per
 450 delivery.  The default limit is more than any reasonable SMTP client
 451 would send. The limit exists to protect the local mail system
 452 against a run-away client. </p>
 453
 454 <h2><a name="hammer">Tuning the frequency of deferred mail delivery attempts</a></h2>
 455
 456 <p> When a Postfix delivery agent (<a href="smtp.8.html">smtp(8)</a>, <a href="local.8.html">local(8)</a>, etc.) is
 457 unable to deliver a message it may blame the message itself, or it
 458 may blame the receiving party. </p>
 459
 460 <ul>
 461
 462 <li> <p> When the delivery agent blames the message, the queue
 463 manager gives the queue file a time stamp into the future, so it
 464 won't be looked at for a while. By default, the amount of time to
 465 cool down is the amount of time that has passed since the message
 466 arrived.  This results in so-called exponential backoff behavior.
 467 </p>
 468
 469 <li> <p> When the delivery agent blames the receiving party (for
 470 example a local recipient user, or a remote host), the queue manager
 471 not only advances the queue file time stamp, but also puts the
 472 receiving party on a "dead" list so that it will be skipped for
 473 some amount of time. </p>
 474
 475 </ul>
 476
 477 <p> This process is governed by a bunch of little parameters. </p>
 478
 479 <blockquote>
 480
 481 <dl>
 482
 483 <dt> <a href="postconf.5.html#queue_run_delay">queue_run_delay</a> (default: 300 seconds; before Postfix 2.4:
 484 1000s) </dt> <dd> How often
 485 the queue manager scans the queue for deferred mail. </dd>
 486
 487 <dt> <a href="postconf.5.html#minimal_backoff_time">minimal_backoff_time</a> (default: 300 seconds; before Postfix
 488 2.4: 1000s) </dt> <dd> The
 489 minimal amount of time a message won't be looked at, and the minimal
 490 amount of time to stay away from a "dead" destination. </dd>
 491
 492 <dt> <a href="postconf.5.html#maximal_backoff_time">maximal_backoff_time</a> (default: 4000 seconds) </dt> <dd> The
 493 maximal amount of time a message won't be looked at after a delivery
 494 failure. </dd>
 495
 496 <dt> <a href="postconf.5.html#maximal_queue_lifetime">maximal_queue_lifetime</a> (default: 5 days) </dt> <dd> How long
 497 a message stays in the queue before it is sent back as undeliverable.
 498 Specify 0 for mail that should be returned immediately after the
 499 first unsuccessful delivery attempt. </dd>
 500
 501 <dt> <a href="postconf.5.html#bounce_queue_lifetime">bounce_queue_lifetime</a> (default: 5 days, available with Postfix
 502 version 2.1 and later) </dt> <dd> How long a MAILER-DAEMON message
 503 stays in the queue before it is considered undeliverable.  Specify
 504 0 for mail that should be tried only once.  </dd>
 505
 506 <dt> <a href="postconf.5.html#qmgr_message_recipient_limit">qmgr_message_recipient_limit</a> (default: 20000) </dt> <dd> The
 507 size of many in-memory queue manager data structures. Among others,
 508 this parameter limits the size of the short-term, in-memory list
 509 of "dead" destinations. Destinations that don't fit the list are
 510 not added. </dd>
 511
 512 </dl>
 513
 514 </blockquote>
 515
 516 <p> IMPORTANT: If you increase the frequency of deferred mail
 517 delivery attempts, or if you flush the deferred mail queue frequently,
 518 then you may find that Postfix mail delivery performance actually
 519 becomes worse. The symptoms are as follows:  </p>
 520
 521 <ul>
 522
 523 <li> <p> The <a href="QSHAPE_README.html#active_queue">active queue</a> becomes saturated with mail that has
 524 delivery problems. New mail enters the <a href="QSHAPE_README.html#active_queue">active queue</a> only when
 525 an old message is deferred. This is a slow process that usually
 526 requires timing out one or more SMTP connections. </p>
 527
 528 <li> <p> All available Postfix delivery agents become occupied
 529 trying to connect to unreachable sites etc. New mail has to wait
 530 until a delivery agent becomes available. This is a slow process
 531 that usually requires timing out one or more SMTP connections. </p>
 532
 533 </ul>
 534
 535 <p> When mail is being deferred frequently, fixing the problem is
 536 always better than increasing the frequency of delivery attempts.
 537 However, if you can control only the delivery attempt frequency,
 538 consider using a dedicated <a href="postconf.5.html#fallback_relay">fallback_relay</a> "graveyard" machine for
 539 bad destinations, so that these destinations do not ruin the
 540 performance of normal
 541 mail deliveries.  </p>
 542
 543 <h2><a name="proc_limit">Tuning the number of Postfix processes</a></h2>
 544
 545 <p> The <a href="postconf.5.html#default_process_limit">default_process_limit</a> configuration parameter gives direct
 546 control over how many daemon processes Postfix will run.  As of
 547 Postfix 2.0 the default limit is 100 smtp client processes, 100
 548 smtp server processes, and so on.  This may overwhelm systems with
 549 little memory, as well as networks with low bandwidth.  </p>
 550
 551 <p> You can change the global process limit by specifying a
 552 non-default <a href="postconf.5.html#default_process_limit">default_process_limit</a> in the <a href="postconf.5.html">main.cf</a> file. For example,
 553 to run up to 10 smtp client processes, 10 smtp server processes,
 554 and so on: </p>
 555
 556 <blockquote>
 557 <pre>
 558 /etc/postfix/<a href="postconf.5.html">main.cf</a>:
 559     <a href="postconf.5.html#default_process_limit">default_process_limit</a> = 10
 560 </pre>
 561 </blockquote>
 562
 563 <p> You need to execute "postfix reload" to make the change effective.
 564 The limits are enforced by the Postfix <a href="master.8.html">master(8)</a> daemon which does
 565 not automatically read <a href="postconf.5.html">main.cf</a> when it changes. </p>
 566
 567 <p> You can override the process limit for specific Postfix daemons
 568 by editing the <a href="master.5.html">master.cf</a> file.  For example, if you do not wish to
 569 receive 100 SMTP messages at the same time, but do not want to
 570 change the process limits for local mail deliveries, you could
 571 specify: </p>
 572
 573 <blockquote>
 574 <pre>
 575 /etc/postfix/<a href="master.5.html">master.cf</a>:
 576     # ====================================================================
 577     # service type  private unpriv  chroot  wakeup  maxproc command + args
 578     #               (yes)   (yes)   (yes)   (never) (100)
 579     # ====================================================================
 580     . . .
 581     smtp      inet  n       -       -       -       10      smtpd
 582     . . .
 583 </pre>
 584 </blockquote>
 585
 586 <h2><a name="proc_sys">Tuning the number of processes on the system</a></h2>
 587
 588 <ul>
 589
 590 <li> <p> MacOS X will run out of process slots when you increase
 591 Postfix process limits. The following works with OSX 10.4 and OSX
 592 10.5. </p>
 593
 594 <p> MacOS X kernel parameters can be specified in /etc/sysctl.conf.
 595 </p>
 596
 597 <pre>
 598 /etc/sysctl.conf:
 599     kern.maxproc=2048
 600     kern.maxprocperuid=2048
 601 </pre>
 602
 603 <p> Unfortunately these can't simply be set on the fly with "sysctl
 604 -w".  You also have to set the following in /etc/launchd.conf so
 605 that the root user after boot will have the right process limit
 606 (2048).  Otherwise you have to always run ulimit -u 2048 as root,
 607 then start a user shell, and then start processes for things to
 608 take effect. </p>
 609
 610 <pre>
 611 /etc/launchd.conf:
 612     limit maxproc 2048
 613 </pre>
 614
 615 <p> Once these are in place, reboot the system.  After that, the limits will
 616 stay in place. </p>
 617
 618 </ul>
 619
 620 <h2><a name="file_limit">Tuning the number of open files or sockets</a></h2>
 621
 622 <p> When Postfix opens too many files or sockets, processes will
 623 abort with fatal errors, and the system may log "file table full"
 624 errors. </p>
 625
 626 <ul>
 627
 628 <li> <p> Depending on your Postfix and operating system versions
 629 you may need to recompile Postfix if you need more than 1024 file
 630 descriptors per process: </p>
 631
 632 <ul> <li> <p> No recompilation is needed for Postfix version 2.4
 633 and later, when it was compiled for systems that support BSD kqueue(2)
 634 (FreeBSD 4.1, NetBSD 2.0, OpenBSD 2.9), Solaris 8 /dev/poll, or
 635 Linux 2.6 epoll(4).  </p>
 636
 637 <li> <p> Otherwise, Postfix needs to be recompiled to override the
 638 default FD_SETSIZE value. </p>
 639
 640 </ul>
 641
 642 <li> <p> Reduce the number of processes as described under "<a
 643 href="#proc_limit">Tuning the number of Postfix processes</a>" above.
 644 Fewer processes need fewer open files and sockets. </p>
 645
 646 <li> <p> Configure the kernel for more open files and sockets.
 647 The details are extremely system dependent and change with the
 648 operating system version. Be sure to verify the following information
 649 with your system tuning guide:  </p>
 650
 651 <ul>
 652
 653 <li> <p> Some FreeBSD kernel parameters can be specified in
 654 /boot/loader.conf, and some can be specified in /etc/sysctl.conf
 655 or changed with sysctl commands.
 656 Which is which depends on the version.
 657 </p>
 658
 659 <pre>
 660 kern.ipc.maxsockets="5000"
 661 kern.ipc.nmbclusters="65536"
 662 kern.maxproc="2048"
 663 kern.maxfiles="16384"
 664 kern.maxfilesperproc="16384"
 665 </pre>
 666
 667 <li> <p> Linux kernel parameters can be specified in /etc/sysctl.conf
 668 or changed with sysctl commands: </p>
 669
 670 <pre>
 671 fs.file-max=16384
 672 kernel.threads-max=2048
 673 </pre>
 674
 675 <li> <p> Solaris kernel parameters can be specified in /etc/system,
 676 as described in the <a
 677 href="http://www.science.uva.nl/pub/solaris/solaris2.html#q3.48">Solaris
 678 FAQ</a> entry titled "How can I increase the number of file
 679 descriptors per process?" </p>
 680
 681 <pre>
 682 * set hard limit on file descriptors
 683 set rlim_fd_max = 4096
 684 * set soft limit on file descriptors
 685 set rlim_fd_cur = 1024
 686 </pre>
 687
 688 </ul>
 689
 690 </ul>
 691
 692 </body>
 693
 694 </html>