[pfx] Re: qmgr stalls when default_destination_rate_delay drops below 1s on a node, with a backed-up queue
Yoda via Postfix-users <[email protected]> Tue, 5 May 2026 10:03:40 -0400
| Newsgroups | gmane.mail.postfix.user |
|---|---|
| Message-ID | <[email protected]> |
Wietse,
Excellent — that's exactly the pattern I didn't know existed. Thank
you for the additional context (and for catching the cut-and-paste
in the first version).
For our current scale we're not pressing the per-destination 60/min
ceiling, so we'll stay on default_destination_* tuning for now. But
the parallel-transports + randmap pattern is now logged in our
internal documentation as the next throughput rung if and when we
need it — between concurrency_limit tuning and provisioning a new
MTA node. Good to have the option without leaving the single-server
config.
Thanks again for the patience walking us all the way through this
thread. Closing on our side.
Yoda
On 5/5/26 9:57 AM, Wietse Venema wrote:
Wietse Venema:
Yoda via Postfix-users:
Our updated tuning rules:
- Minimum rate_delay is 1s. Sub-second is architecturally
impossible at the rate_delay knob, full stop.
- Always set time values at default_destination_* (qmgr fatals
It is possible if you can afford to configure multiple delivery transports
that have parallel rate delays.
Below is an old posting.
Wietse
I'm working in an email marketing firm, we send more than 50 millions of
emails per month, and use postfix for that, and can't resolve a problem
with transport for gmail, in destination_rate_delay, only
accepts integers, why can not use a float?
The rate delay feature was implemented for end users with an ISP
that allows only a limited volume of outbound email (less than
3600/hour). It turned out to also help for sending mail to providers
such as Hotmail with very low rate limits.
The rate delay implementation does not work well for bulk mail,
because it limits the concurrency to only one delivery at a time.
So the proper fix is not changing ints to float, but allowing more
than one delivery at a time.
However, you can increase concurrency by using multiple SMTP
transports and random selection.
Damn!. Cut and paste error.
Wietse
In /etc/postfix/master.cf:
smtp1 unix - - n - - smtp
smtp2 unix - - n - - smtp
...
smtpN unix - - n - - smtp
smtp1_destination_concurrency_failed_cohort_limit = 10
smtp2_destination_concurrency_failed_cohort_limit = 10
...
smtpN_destination_concurrency_failed_cohort_limit = 10
In /etc/postfix/main.cf:
smtp1_destination_rate_delay = 1
smtp2_destination_rate_delay = 1
...
smtpN_destination_rate_delay = 1
transport_maps =
inline:{
{ $myhostname = $local_transport }
{ localhost = $local_transport }
{ localhost.$mydomain = $local_transport }
# Other domains that don't deliver over SMTP...
} randmap:{ smtp1:, smtp2:, ..., smtpN: }
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]