From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | 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:03:25 |
Message-ID: | 405330CD.4050304@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
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?
Yes, a full postmaster restart is needed. It is a command line script
that does the insert, so each one is a new backend.
> Are you using particularly large values for shared_buffers or any of the
> other resource parameters?
I'll have to look at this again (I have to vpn in to the company lan
which kills all my current connections) -- the server and application
belong to another department at my employer.
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).
I'll post the non-default postgresql.conf settings shortly. The extended
tests discussed in the nearby post will take a bit more time to get.
Thanks,
Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2004-03-13 16:07:12 | Re: rapid degradation after postmaster restart |
Previous Message | Joe Conway | 2004-03-13 15:51:48 | Re: rapid degradation after postmaster restart |
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2004-03-13 16:07:12 | Re: rapid degradation after postmaster restart |
Previous Message | Joe Conway | 2004-03-13 15:51:48 | Re: rapid degradation after postmaster restart |