Re: rapid degradation after postmaster restart

From: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: rapid degradation after postmaster restart
Date: 2004-03-13 17:33:43
Message-ID: 405345F7.7080803@zeut.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

Joe Conway wrote:

> Tom Lane wrote:
>
>> Just to be clear on this: you have to restart the postmaster to bring
>> the time back down? Simply starting a fresh backend session doesn't do
>> it?
>
>
> 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 could be a problem if it's vacuuming too often. Have you
looked to see if a vacuum or analyze is running while the server is
slow? If so, have you played with the pg_autovacuum default vacuum and
analyze thresholds? If it appears that it is related to pg_autovacuum
please send me the command options used to run it and a logfile of it's
output running at at a debug level of -d2

Matthew

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fernando Nasser 2004-03-13 18:00:10 Re: Log rotation
Previous Message Patrick Welche 2004-03-13 17:26:02 Re: Log rotation

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2004-03-13 23:17:08 Re: High CPU with 7.4.1 after running for about 2 weeks
Previous Message Josh Berkus 2004-03-13 16:51:22 Re: rapid degradation after postmaster restart