Hi There,
We have been running Postfix successfully for months now. We sent an email to two subscriber groups last night. We monitor the number of emails we send per minute with the following report: 00:30 541 564 601 655 633 498 376 342 615 498 00:40 512 455 485 432 609 525 443 211 0 0 00:50 2 0 0 0 0 0 0 0 0 0 01:00 0 9 15 11 10 14 14 12 12 15 01:10 9 13 13 10 14 11 16 12 14 12 01:20 14 14 12 14 20 9 14 12 15 15 01:30 13 12 12 17 12 12 12 11 15 10 The first group started at 00:30 and sent about 500 emails per minute for a total of 9,000 emails. This is what we expect as this work is being done with four randmap transports with one IP and two processes each. We are in the middle of a migration and have our send rate intentionally slowed down until the migration to new IP addresses is complete. The second group started at 01:00. The send rate changed from 500 emails sent per minute to 15 emails per minute. We are still delivering this email as I type this. I reviewed the email logs and the vast majority of the email is "status=sent" -- there are few errors and no greylisting from the ISPs. This is what I would expect at this send rate -- clean maillogs. I contacted the Network Team of our new Colocation. They say they do not throttle port 25 -- just turn it off if needed. I need to figure out a way to tell if the slow down is with Postfix (which I doubt) or if email delivery is being slowed by an external force of some kind -- not the ISPs. I am spending a good deal of time with tcpdump and iptraf but am unsuccessful so far. Any ideas? Thanks, Greg www.RayStedman.org |
Greg Sims:
> Hi There, > > We have been running Postfix successfully for months now. We sent an > email to two subscriber groups last night. We monitor the number of > emails we send per minute with the following report: > > 00:30 541 564 601 655 633 498 376 342 > 615 498 > 00:40 512 455 485 432 609 525 443 211 > 0 0 > 00:50 2 0 0 0 0 0 0 0 > 0 0 > > 01:00 0 9 15 11 10 14 14 12 > 12 15 > 01:10 9 13 13 10 14 11 16 12 > 14 12 > 01:20 14 14 12 14 20 9 14 12 > 15 15 > 01:30 13 12 12 17 12 12 12 11 > 15 10 > > The first group started at 00:30 and sent about 500 emails per minute > for a total of 9,000 emails. This is what we expect as this work is > being done with four randmap transports with one IP and two processes > each. We are in the middle of a migration and have our send rate > intentionally slowed down until the migration to new IP addresses is > complete. > > The second group started at 01:00. The send rate changed from 500 > emails sent per minute to 15 emails per minute. We are still > delivering this email as I type this. > > I reviewed the email logs and the vast majority of the email is > "status=sent" -- there are few errors and no greylisting from the > ISPs. This is what I would expect at this send rate -- clean > maillogs. > > I contacted the Network Team of our new Colocation. They say they do > not throttle port 25 -- just turn it off if needed. I need to figure > out a way to tell if the slow down is with Postfix (which I doubt) or > if email delivery is being slowed by an external force of some kind -- > not the ISPs. I am spending a good deal of time with tcpdump and > iptraf but am unsuccessful so far. Any ideas? First, do a bandwidth test. Second, on the sending system, look at the TCP window size of outbound port 25 traffic. Maybe filter only one destination. If the receiver's TCP window size is persistenly small, then either the receiver is trying to slow you down, or some traffic shaping box in the middle. Third, look with mtr at the latency pattern. If part of your traffic goes over a satellite, of if it is tunneled to some far-away country, then you will see a big jump. Unfortunately, mtr does not support tcp so you can't do 'mtr for port 25'. That's just a few off the top of my head. Wietse |
In reply to this post by Greg Sims
On Sun, Mar 28, 2021 at 01:30:49PM -0700, Greg Sims wrote:
> The second group started at 01:00. The send rate changed from 500 > emails sent per minute to 15 emails per minute. We are still > delivering this email as I type this. Have you looked at the distribution of the "c/d" values in the "delays=a/b/c/d" log entries? If none of the deliveries match "dsn=[45]", then the most likely reason for delays is slow transactions (c = connection setup delay, d = transaction delay). -- Viktor. |
In reply to this post by Wietse Venema
On Monday, 29 March 2021 9:34:13 AM AEDT Wietse Venema wrote:
... > Third, look with mtr at the latency pattern. If part of your traffic > goes over a satellite, of if it is tunneled to some far-away country, > then you will see a big jump. Unfortunately, mtr does not support > tcp so you can't do 'mtr for port 25'. mtr supports tcp syn based probes these days. mtr --tcp -P 25 destination_host should do the trick > > That's just a few off the top of my head. > > Wietse |
Great ideas guys -- Thanks! Greg On Mon, Mar 29, 2021 at 7:26 AM Richard James Salts <[hidden email]> wrote: On Monday, 29 March 2021 9:34:13 AM AEDT Wietse Venema wrote: |
Free forum by Nabble | Edit this page |