Re: rapid degradation after postmaster restart - Mailing list pgsql-performance

From Josh Berkus
Subject Re: rapid degradation after postmaster restart
Date
Msg-id 200403130851.22684.josh@agliodbs.com
Whole thread Raw
In response to Re: rapid degradation after postmaster restart  (Joe Conway <mail@joeconway.com>)
List pgsql-performance
Joe,

> IIRC, shared buffers was reasonable, maybe 128MB. One thing that is
> worthy of note is that they are using pg_autovacuum and a very low
> vacuum_mem setting (1024). But I also believe that max_fsm_relations and
> max_fsm_pages have been bumped up from default (something like 10000 &
> 200000).

pg_autovacuum may be your problem.   Imagine this:

1) The chain of updates and inserts called by the procedures makes enough
changes, on its own, to trigger pg_autovacuum.
2) Because they have a big database, and a low vacuum_mem, a vacuum of the
largest table takes noticable time, like several minutes.
3) This means that the vacuum is still running during the second and
succeeding events ....

Something to check by watching the process list.

FWIW, I don't use pg_autovacuum for databases which have frequent large batch
updates; I find it results in uneven performance.

Feel free to phone me if you're still stuck!

--
-Josh Berkus
 Aglio Database Solutions
 San Francisco


pgsql-performance by date:

Previous
From: Joe Conway
Date:
Subject: Re: rapid degradation after postmaster restart
Next
From: "Matthew T. O'Connor"
Date:
Subject: Re: rapid degradation after postmaster restart