Re: rapid degradation after postmaster restart

Поиск
Список
Период
Сортировка
От Matthew T. O'Connor
Тема Re: rapid degradation after postmaster restart
Дата
Msg-id 405345F7.7080803@zeut.net
обсуждение исходный текст
Ответ на Re: rapid degradation after postmaster restart  (Joe Conway <mail@joeconway.com>)
Список 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


В списке pgsql-performance по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: rapid degradation after postmaster restart
Следующее
От: Joseph Shraibman
Дата:
Сообщение: Re: optimizing large query with IN (...)