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

From Matthew T. O'Connor
Subject Re: rapid degradation after postmaster restart
Date
Msg-id 405345F7.7080803@zeut.net
Whole thread Raw
In response to Re: rapid degradation after postmaster restart  (Joe Conway <mail@joeconway.com>)
List 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


pgsql-performance by date:

Previous
From: Josh Berkus
Date:
Subject: Re: rapid degradation after postmaster restart
Next
From: Joseph Shraibman
Date:
Subject: Re: optimizing large query with IN (...)