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
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 |
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 |