Обсуждение: Slower bounce-back of commit messages
It seems like sometime in the past few days, the throughput of the
PG mail system dropped substantially. The particular symptom I'm
noticing is that when I push multiple commits, it used to be
that the pgsql-committers traffic came back (a) within a few seconds
and (b) all together. Now it takes a few minutes for them to trickle in,
as in this example of seven commits that were pushed together:
From pgsql-committers-owner+M15-102287@lists.postgresql.org Wed Nov 14 16:40:31 2018
Subject: pgsql: Doc: remove claim that all \pset format options are unique in
From pgsql-committers-owner+M15-102288@lists.postgresql.org Wed Nov 14 16:40:35 2018
Subject: pgsql: Doc: remove claim that all \pset format options are unique in
From pgsql-committers-owner+M15-102292@lists.postgresql.org Wed Nov 14 16:43:57 2018
Subject: pgsql: Doc: remove claim that all \pset format options are unique in
From pgsql-committers-owner+M15-102289@lists.postgresql.org Wed Nov 14 16:44:20 2018
Subject: pgsql: Doc: remove claim that all \pset format options are unique in
From pgsql-committers-owner+M15-102290@lists.postgresql.org Wed Nov 14 16:44:34 2018
Subject: pgsql: Doc: remove claim that all \pset format options are unique in
From pgsql-committers-owner+M15-102293@lists.postgresql.org Wed Nov 14 16:44:43 2018
Subject: pgsql: Make psql's "\pset format" command reject non-unique
From pgsql-committers-owner+M15-102291@lists.postgresql.org Wed Nov 14 16:44:52 2018
Subject: pgsql: Doc: remove claim that all \pset format options are unique in
I've also noticed slower turnaround on some of the other lists.
What's up?
regards, tom lane
On 11/14/18 10:52 PM, Tom Lane wrote: > It seems like sometime in the past few days, the throughput of the > PG mail system dropped substantially. The particular symptom I'm > noticing is that when I push multiple commits, it used to be > that the pgsql-committers traffic came back (a) within a few seconds > and (b) all together. Now it takes a few minutes for them to trickle in, > as in this example of seven commits that were pushed together: > > From pgsql-committers-owner+M15-102287@lists.postgresql.org Wed Nov 14 16:40:31 2018 > Subject: pgsql: Doc: remove claim that all \pset format options are unique in > From pgsql-committers-owner+M15-102288@lists.postgresql.org Wed Nov 14 16:40:35 2018 > Subject: pgsql: Doc: remove claim that all \pset format options are unique in > From pgsql-committers-owner+M15-102292@lists.postgresql.org Wed Nov 14 16:43:57 2018 > Subject: pgsql: Doc: remove claim that all \pset format options are unique in > From pgsql-committers-owner+M15-102289@lists.postgresql.org Wed Nov 14 16:44:20 2018 > Subject: pgsql: Doc: remove claim that all \pset format options are unique in > From pgsql-committers-owner+M15-102290@lists.postgresql.org Wed Nov 14 16:44:34 2018 > Subject: pgsql: Doc: remove claim that all \pset format options are unique in > From pgsql-committers-owner+M15-102293@lists.postgresql.org Wed Nov 14 16:44:43 2018 > Subject: pgsql: Make psql's "\pset format" command reject non-unique > From pgsql-committers-owner+M15-102291@lists.postgresql.org Wed Nov 14 16:44:52 2018 > Subject: pgsql: Doc: remove claim that all \pset format options are unique in > > I've also noticed slower turnaround on some of the other lists. > What's up? we have recently spent a fair amount of effort in optimizing delivery times for large delivery bursts (especially concurrent approvals for mails on -announce) which caused very large load on the emailinglist box and way too aggressive backoff in delivery afterwards. That aggressive backoff caused excessive delays for a very large number of recipients - the current setup copes with that scenario much better however it puts deliveries for smaller lists (like pgsql-committers) at a disadvantage because we stepping down aggressive deliveries a little bit too early. We are still working on further refining the system but as with every optimization if you optimize for one scenario you might put another one at a disadvantage :( Stefan
Greetings, * Stefan Kaltenbrunner (stefan@kaltenbrunner.cc) wrote: > On 11/14/18 10:52 PM, Tom Lane wrote: > > It seems like sometime in the past few days, the throughput of the > > PG mail system dropped substantially. The particular symptom I'm > > noticing is that when I push multiple commits, it used to be > > that the pgsql-committers traffic came back (a) within a few seconds > > and (b) all together. Now it takes a few minutes for them to trickle in, > > as in this example of seven commits that were pushed together: > > > > From pgsql-committers-owner+M15-102287@lists.postgresql.org Wed Nov 14 16:40:31 2018 > > Subject: pgsql: Doc: remove claim that all \pset format options are unique in > > From pgsql-committers-owner+M15-102288@lists.postgresql.org Wed Nov 14 16:40:35 2018 > > Subject: pgsql: Doc: remove claim that all \pset format options are unique in > > From pgsql-committers-owner+M15-102292@lists.postgresql.org Wed Nov 14 16:43:57 2018 > > Subject: pgsql: Doc: remove claim that all \pset format options are unique in > > From pgsql-committers-owner+M15-102289@lists.postgresql.org Wed Nov 14 16:44:20 2018 > > Subject: pgsql: Doc: remove claim that all \pset format options are unique in > > From pgsql-committers-owner+M15-102290@lists.postgresql.org Wed Nov 14 16:44:34 2018 > > Subject: pgsql: Doc: remove claim that all \pset format options are unique in > > From pgsql-committers-owner+M15-102293@lists.postgresql.org Wed Nov 14 16:44:43 2018 > > Subject: pgsql: Make psql's "\pset format" command reject non-unique > > From pgsql-committers-owner+M15-102291@lists.postgresql.org Wed Nov 14 16:44:52 2018 > > Subject: pgsql: Doc: remove claim that all \pset format options are unique in > > > > I've also noticed slower turnaround on some of the other lists. > > What's up? > > we have recently spent a fair amount of effort in optimizing delivery > times for large delivery bursts (especially concurrent approvals for > mails on -announce) which caused very large load on the emailinglist box > and way too aggressive backoff in delivery afterwards. > That aggressive backoff caused excessive delays for a very large number > of recipients - the current setup copes with that scenario much better > however it puts deliveries for smaller lists (like pgsql-committers) at > a disadvantage because we stepping down aggressive deliveries a little > bit too early. > We are still working on further refining the system but as with every > optimization if you optimize for one scenario you might put another one > at a disadvantage :( We have now taken the next step in 'optimization' and basically thrown a bunch more hardware at the problem (well, and some other minor tuning, but most of it was adding a bunch more CPUs). We will continue to keep an eye on things, of course, and continue to tune but hopefully this will help. Thanks! Stephen