Re: rapid degradation after postmaster restart

Поиск
Список
Период
Сортировка
От Joe Conway
Тема Re: rapid degradation after postmaster restart
Дата
Msg-id 405330CD.4050304@joeconway.com
обсуждение исходный текст
Ответ на Re: rapid degradation after postmaster restart  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: rapid degradation after postmaster restart
Re: rapid degradation after postmaster restart
Список 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 по дате отправления:

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: rapid degradation after postmaster restart
Следующее
От: Joe Conway
Дата:
Сообщение: Re: rapid degradation after postmaster restart