Почему Postgres постепенно все сильнее нагружает процессор при постоянной нагрузке?

Question

[Максим Кадочников]

Платформа: windows.
Имеется Postgres и приложение на node.js. В процессе работы приложения к базе производится порядка 20-30 запросов в секунду (чтение и запись).
Проблема заключается в том, что после запуска приложения на node.js, Posgres начинает потреблять процессор по нарастающей. Т.е. на момент запуска приложения нагрузка на процессор со стороны базы составляет несколько процентов, на запросы база отвечает очень быстро, можно сказать, что "все летает". Уже через полчаса нагрузка составляет порядка 10%, запросы чуть притормаживают. Еще через полчаса нагрузка со стороны базы на процессор составляет уже порядка 50%, количество выполняемых запросов падает до 10-15, т.е. в два раза по сравнению с запуском. И так вплоть до того, что загрузка ЦП доходит до 100% и "все тормозит".
При этом процессы Posgres так же увеличивают потребление ОЗУ, но его хватает и база не потребляет больше 10 GB из 24Gb, имеющихся на машине.
Проблема решается перезапуском приложения на node.js. Т.е. если его прибить и запустить снова - то все начинается с начала. Такое ощущение, что Posgres кэширует что-то для активных соединений и поиск в этом кэше грузит процессор. Т.к. если зайти в базу через PGAdmin и выполнить запрос оттуда - то он выполняется быстро.

Запросы со стороны node.js осуществляются посредством Sequelize через пул из 5-ти соединений.
Размер базы порядка 15Gb вместе со всеми индексами. Тяжелых запросов нет. Время выполнения запросов исчисляется милисекундами.
Конфиг Postgres: pastebin.com/Vm1jp7VB
Процессор: Core i5-3570K (4 ядра)
ОЗУ: 24Gb.

Comments

[sim3x]

Конфиг нужно вставить в тег code прямо сюда

И прояснить
>Проблема решается перезапуском приложения на node.js.
но виноват
>Почему Postgres

[Максим Кадочников]

Я не утверждаю, что дело в Posgres. Я лишь констатирую факт, что именно он поедает процессор по нарастающей и старюсь максимально подробно описать ситуацию.

[Максим Кадочников]

sim3x: Конфиг сюда не влазит. Редактор ругается, что больше 10000 символов

[sim3x]

Максим Кадочников: гист

[Falseclock]

sim3x: pastebin.com

[sim3x]

Максим Кадочников: И прояснить
>Проблема решается перезапуском приложения на node.js.
но виноват
>Почему Postgres

[Falseclock]

проблема в том, что конфиг не поможет в данной ситуации. Ну стоит shared_buffers = 512MB, а какие запросы там пролетают не известно. Если запрос вида

SELECT * FROM foo + 20 джоинов, где в каждой таблице по 30 полей

, то никакой буфер не поможет и база будет аццки тормозить, потому что диск напрягается туда сюда читать-записывать. Пока не будет ответа какие запросы тормозят и какова структура таблиц - помочь не возможно.

work_mem = 15728kB какое-то странное значение. От куда оно? Оно не кратно ни 32 ни 64.

короче смотреть че тормозит, потом думать дальше.

Answer 1

[terrier]

Посмотрите в pg_stat_activity - никто на локах не зависает? Запросы по часу не исполняются? Соединений получается точно пять?

Comments

[Falseclock]

локи как раз начинаются когда обновиться таблица не может либо из-за конкуретного селекта либо наоборот. И это все упирается в структура таблицы, индекса и тип запросов. Так что сперва определить что там тормозит через логирование длинных запросов, а потом уже понимать почему в активити локи стоят колом.

[terrier]

Я бы с более общего случая начал - определить, что тормозит именно обработка запросов на бэкэндах (т.е. видимо совместный доступ к таблице), а не чекпоинты/автовакуум/что-то еще