Re: rapid degradation after postmaster restart

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

In response to

Responses

Browse pgsql-hackers by date

  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

Browse pgsql-performance by date

  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