Обсуждение: Very long COMMIT times?
We've been adjusting the WAL log file count on our database. The only effects we've seen so far in increasing the count from 8 (default) to 32 (current) are: 1) No more WAL messages in the log 8-/ and 2) very long COMMIT times for some long transactions: I'm talking about upwards of 10-20 MINUTES to commit after doing hundreds of inserts, updates and deletes in one transaction. The table involved has some 20K rows, and is read and updated a few rows at a time by many processes, but only one (the one doing large numbers of rows) has the lengthy COMMIT times. Did this come about because of the increase in WAL count? -- Jeff Boes vox 616.226.9550 Database Engineer fax 616.349.9076 Nexcerpt, Inc. jboes@nexcerpt.com
In article <9sphq7$k0h$1@news.tht.net>, "Jeff Boes" <jboes@nexcerpt.com> wrote: > and 2) very long COMMIT times for some long transactions: I'm talking > about upwards of 10-20 MINUTES to commit after doing hundreds of > inserts, updates and deletes in one transaction. The table involved has > some 20K rows, and is read and updated a few rows at a time by many > processes, but only one (the one doing large numbers of rows) has the > lengthy COMMIT times. > > Did this come about because of the increase in WAL count? Oops. This turns out not to be a COMMIT time, but instead it's happening in a NOTIFY operation just after the COMMIT. What would cause a previously-quick NOTIFY step to become many minutes long? -- Jeff Boes vox 616.226.9550 Database Engineer fax 616.349.9076 Nexcerpt, Inc. jboes@nexcerpt.com
"Jeff Boes" <jboes@nexcerpt.com> writes:
>> Did this come about because of the increase in WAL count?
No.
> Oops. This turns out not to be a COMMIT time, but instead it's happening
> in a NOTIFY operation just after the COMMIT. What would cause a
> previously-quick NOTIFY step to become many minutes long?
Have you vacuumed pg_listener recently?
regards, tom lane