PostgreSQL и 1С: как построить систему поиска «тихих убийц» производительности

[arxbz]

Классная инструкция, спасибо!

[peta0982]

Рад, что статья нашла отклик, спасибо!

[z_serg]

Sequential Scan не вымывает кэш, а работает в буферном кольце.

[peta0982]

Спасибо за поправку! Ошибся в этом моменте — про кольцевой буфер и Buffer Access Strategy не знал, изучу.
Мой фокус в этом кейсе был больше на методике регулярной проверки: как через pgbadger и системный анализ планов находить и устранять узкие места в СУБД

[bzq]

Если pgbadger заменить на pg_stat_statements, то логи расти и замусориваться запросами не будут, а статистика станет точной. Вас будет интересовать топ по полю shared_blks_hit. Можно ещё добавить pg_profile для поиска аномалий. Сам подход правильный.

[peta0982]

Спасибо за наводку. Пробовал использовать pg_stat_statements, но в итоге вернулся к логам и pgbadger.

Мне в работе оказалась полезна ретроспектива: например, если 1 января вышло обновление с багом, в агрегированной статистике pg_stat_statements я увижу только "среднюю температуру" за всё время. Логи же позволяют "отмотать пленку" назад и сравнить производительность по конкретным дням или неделям. Так же парсинг логов через pgbadger можно вынести на отдельный сервер.
Возможно, я просто еще не до конца раскрыл для себя потенциал pg_stat_statements, но для еженедельного аудита формат pgbadger мне показался нагляднее.

[bzq]

А для ретроспективы как раз pg_profile и пригодится.