From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: rapid degradation after postmaster restart |
Date: | 2004-03-13 16:51:22 |
Message-ID: | 200403130851.22684.josh@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers 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
From | Date | Subject | |
---|---|---|---|
Next Message | Patrick Welche | 2004-03-13 17:26:02 | Re: Log rotation |
Previous Message | Joe Conway | 2004-03-13 16:07:12 | Re: rapid degradation after postmaster restart |
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew T. O'Connor | 2004-03-13 17:33:43 | Re: rapid degradation after postmaster restart |
Previous Message | Joe Conway | 2004-03-13 16:07:12 | Re: rapid degradation after postmaster restart |