| 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: | Whole Thread | Raw Message | 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 |