Re: rapid degradation after postmaster restart

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

In response to

Browse pgsql-hackers by date

  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

Browse pgsql-performance by date

  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