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

From Joe Conway
Subject Re: rapid degradation after postmaster restart
Date
Msg-id 405330CD.4050304@joeconway.com
Whole thread Raw
In response to Re: rapid degradation after postmaster restart  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: rapid degradation after postmaster restart  (Josh Berkus <josh@agliodbs.com>)
Re: rapid degradation after postmaster restart  ("Matthew T. O'Connor" <matthew@zeut.net>)
List 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


pgsql-performance by date:

Previous
From: Joe Conway
Date:
Subject: Re: rapid degradation after postmaster restart
Next
From: Joe Conway
Date:
Subject: Re: rapid degradation after postmaster restart