6.4. MTA Performance Tuning Tips for Postfix

See also the Postfix Performance Tuning page at http://www.postfix.org/TUNING_README.html.

As lists get larger, Postfix delivery with out-of-the box configuration really slows down. The bottlenecks I've found are queue length and number of SMTP processes, both of which default to values too small for large lists. I began noticing pretty severe rate limiting at about 10,000 deliveries on a list.

To get the number of SMTP processes up, change "default_process_limit" in main.cf.

  default_process_limit = 150

gave results I could live with. Note that this depends on your hardware, especially on the speed of your disks.

Also, you can increase the max. number of recipients per message that Postfix is willing to accept: smtpd_recipient_limit = 1000 to something larger (10.000 maybe)

There's an active message queue which also became a sticky wicket for us. Two limits which affect this, and the values I arrived at by experiment are:

  qmgr_message_active_limit = 40000
  qmgr_message_recipient_limit = 40000

Default on both of these is 20.000. The comments in the config file say:

  # The qmgr_message_active_limit parameter limits the number of
  # messages in the active queue.

  # The qmgr_message_recipient_limit parameter limits the number of
  # in-memory recipients. This parameter also limits the size of the
  # short-term, in-memory destination status cache.

Rather use nqmgr than qmgr.

With these changes in place, a K6-350 with 128M RAM delivers messages averaging perhaps 3K over a medium-speed DSL, without entirely saturating the DSL, at load average below 2.0, without impinging on swap. It'll reach 20,000 recipients in a couple of hours.

Another common recommendation with Postfix is to set

  disable_dns_lookups = yes

a measure others have reported favorably on, but which I have not yet tried.

After changing parameters in main.cf, run "postfix reload" then look at the process table to see if the postfix processes are running, and how many smtp processes are working at it.

  mailq

gives a report of what's in process and is a great help in tuning. Unfortunately, running mailq competes for the same resource (the disk). Thus running mailq often will considerably slow down your delivery! A crude index of what's out there is

  mailq | grep '^[A-Z0-9]' | wc -l

and variations.

Following some other comments on mailing list, this from Ralf Hildebrandt

I began to see signs of thrashing some place between a couple of thousand recipients, and 10,000. There was what appeared to be a phase transition of sorts, above which waits began to predominate and I believe delivery rate may have even gone down.

I'm not getting anything like 1400 deliveries/minute (I don't think). I'll try measuring delivery rate during this week's large announce-lists posting, then next week set disable_dns_lookups and see what change there may be.

The DSL does get to be pretty much of a nuisance to run vi on over an ssh connection, when the list mail is going out.

The local copy of BIND is something I'd neglected to mention. We use split DNS, with internal copies of BIND claiming to be definitive for our domain, forwarding queries with respect to other domains outside. The mailing list server does auxilliary duty as second internal MX server, so there's a copy of BIND running on it, as well as Postfix/Mailman. It looks to itself first for all name resolution.

Comments from Brad Knowles

Regarding the "disable_dns_lookups" advice given above, note that you do NOT want to do this on your main postfix instance. Instead, run a second copy of postfix with a reduced configuration on a different port (e.g., localhost:10025), and turn off virtually all checks, including anti-virus, anti-spam, greylisting, authentication, DNS lookups, etc....

You won't need any of these things on the second postfix instance, because they were all done when the messages came in on the primary postfix instance – before the messages were handed over to Mailman. This allows you to run a configuration that is tuned for maximum performance on an alternative port. Make sure that this second instance is only reachable on the LOCALHOST interface (127.0.0.1), because otherwise people will be spamming through your machine on this port.

You may also want to tune for higher parallelism in your connections, especially if you use VERP and/or personalization, since those features will reduce the number of recipients you get per message and increase the probability that multiple messages will be going to the same sets of destination mail servers.

You may also want to tune for faster queue retry periods than normal, especially if greylisting is in common use amongst your members or their mail systems. This will help ensure that messages are retried more frequently, and more mail should be pushed through faster.

Here are some sample performance tuning settings that we currently use on python.org:

 default_destination_concurrency_limit=50
 default_destination_recipient_limit=50
 default_process_limit=200
 smtp_mx_session_limit=100
 smtpd_client_connection_count_limit=100
 smtp_destination_concurrency_limit=100
 maximal_backoff_time = 1000s
 minimal_backoff_time = 300s

I also highly recommend that you get the book The Book of Postfix: State-of-the-Art Message Transport by Ralf Hildebrandt. Note that Ralf himself made some comments earlier in this FAQ entry, based on his own personal experience with his servers. Ralf's the kind of guy who digs in deep on subjects that interest him, and then later discovers that he's learned enough about the subject that he could write a book on it – and then does, but also continues to stay in the game, and continues to learn and write about the subject.

You may also be interested in the O'Reilly book Postfix: The Definitive Guide by Kyle Dent. I own both books and recommend them both, but if you were to have only one book on this subject, then I would suggest Ralf's would be the better choice.

Converted from the Mailman FAQ Wizard

This is one of many Frequently Asked Questions.