Здравствуйте, dimb82, Вы писали:

D>Что ещё можно попробовать?

Запросы-то какие? Какая схема данных? Какие индексы имеются? Сколько записей в таблицах? Какие размеры таблиц?

По описанным симптомам первая мысль, что вакуум не справляется и таблицы поплыли. Но вообще может быть куча вариантов.

Кстати безусловное увеличение shared memory может иногда приводить к противоположным ожидаемым результатам. БД может начать "захлёбываться" во время чекпоинтов. См. например тут:

And, if you can't fit the entire working set inside shared_buffers, then there are a number of reasons to keep it relatively small, in line with the formula above. If the working set is larger than shared_buffers, most buffer accesses will miss the database buffer cache and fault a page in from the OS; clearly, it makes no sense to allocate a large amount of memory to a cache with a low hit rate. Furthermore, as dirty pages get pushed out of PostgreSQL's cache, they'll enter the operating system cache. If that cache is relatively large, the OS has more freedom to reorder writes and thus schedule the I/O more efficiently. This is especially important around checkpoint time, when the amount of additional dirty data that is pushed out into the OS cache figures to increase with shared_buffers; thus, a higher value for shared_buffers can contribute to latency spikes around checkpoint time.

Здравствуйте, dimb82, Вы писали:

D>Что ещё можно попробовать?

Запросы-то какие? Какая схема данных? Какие индексы имеются? Сколько записей в таблицах? Какие размеры таблиц?

По описанным симптомам первая мысль, что вакуум почему-то не справляется и таблицы/индексы поплыли. Поэтому первым делом я бы проверил эту версию скриптами вот отсюда. Если таблицы и/или индексы раздулись, то надо смотреть почему. Может быть есть idle in trasaction или присутствуют холостые апдейты...

Но вообще может быть куча вариантов почему всё так тормозит.

Кстати безусловное увеличение shared memory может иногда приводить к противоположным ожидаемым результатам. БД может начать "захлёбываться" во время чекпоинтов. См. например тут:

And, if you can't fit the entire working set inside shared_buffers, then there are a number of reasons to keep it relatively small, in line with the formula above. If the working set is larger than shared_buffers, most buffer accesses will miss the database buffer cache and fault a page in from the OS; clearly, it makes no sense to allocate a large amount of memory to a cache with a low hit rate. Furthermore, as dirty pages get pushed out of PostgreSQL's cache, they'll enter the operating system cache. If that cache is relatively large, the OS has more freedom to reorder writes and thus schedule the I/O more efficiently. This is especially important around checkpoint time, when the amount of additional dirty data that is pushed out into the OS cache figures to increase with shared_buffers; thus, a higher value for shared_buffers can contribute to latency spikes around checkpoint time.