PG_EXPECTO: Анализ влияния размера shared_buffers на производительность СУБД PostgreSQL https://habr.com/p/976344/

Общий вывод
Серия экспериментов подтвердила стабильность работы PostgreSQL под различными типами нагрузки. Увеличение параметра shared_buffers не оказало существенного влияния на производительность в данной тестовой конфигурации, что может указывать на:
Достаточность базового значения (2GB) для данной нагрузки
Преобладание других факторов, ограничивающих производительность (CPU, типы запросов, блокировки)
Наиболее значимыми факторами производительности оказались:
Типы выполняемых запросов (особенно JOIN-операции)
Управление блокировками (LWLOCK)
Эффективность использования оперативной памяти
Нагрузка на CPU
Методология испытаний с использованием pg_expecto показала свою эффективность для комплексного анализа производительности СУБД, позволяя выявлять узкие места на разных уровнях системы.

· Администраторам БД и разработчикам, которым нужен повторяемый и документируемый процесс настройки.
· Всем, кто устал от советов «ставьте 25% от RAM» и хочет понять реальное влияние shared_buffers на свою конкретную нагрузку.👍
· Энтузиастам, интересующимся применением ИИ для анализа метрик СУБД.

Работа заслуживает высокой оценки за структурированный подход и практическую направленность. Ее главная сила — не в готовых ответах, а в предоставлении правильного метода для их получения. Рекомендую к внимательному прочтению всем, кто серьезно занимается тонкой настройкой PostgreSQL.

https://rinace.livejournal.com/3059875.html

Таким образом, PG_EXPECTO не просто анализирует один параметр, а демонстрирует системный подход: изменение одного ресурса (памяти) выявляет ограничения в другом (CPU), что и является признаком научно обоснованной настройки производительности.
https://habr.com/p/976564/

Анонс следующей статьи:"PG_EXPECTO: Анализ влияния work_mem на операции в памяти СУБД PostgreSQL"

https://dzen.ru/a/aULBju4l2iRx7gNd
Параметр work_mem важен для устранения операций ввода-вывода на диск при выполнении сортировок и хеш-соединений, однако его увеличение не является панацеей для повышения производительности.

Для данной нагрузки и конфигурации достаточно значений в диапазоне 8–16 МБ.

Дальнейший рост производительности должен достигаться за счёт оптимизации других аспектов СУБД и инфраструктуры, таких как настройка блокировок, параллелизма и управления таймаутами.

Анонс следующей статьи: "Анализ влияния checkpoint_timeout на производительность СУБД при смешанной нагрузке SELECT/INSERT/DELETE"

1. Цель и гипотеза

· Цель: Определить оптимальное значение параметра checkpoint_timeout для конфигурации 8 CPU / 8 GB RAM под смешанной OLTP-нагрузкой (SELECT/INSERT/UPDATE/DELETE) с варьируемой интенсивностью (5-22 конкурентных соединения на тип запроса), обеспечивающее максимальную общую пропускную способность (TPS) и минимальную среднюю задержку (latency).
· Основная гипотеза: Существует нелинейная зависимость между checkpoint_timeout и производительностью. При увеличении значения от минимального (5 мин) производительность будет расти, достигнет «плато» (оптимальный диапазон), после чего либо стабилизируется, либо начнёт снижаться из-за чрезмерно долгих и интенсивных операций записи во время контрольной точки. Гипотеза для проверки: оптимальный диапазон лежит между 10 и 45 минутами.

Первые эксперименты по теме checkpoint_timeout , проведены. Материала собрано много , идет анализ. Пока , без неожиданностей. Результаты предыдущих экспериментов подтверждены - уменьшение checkpoint_timeout это хорошо .

Для большинства продуктивных-сценариев checkpoint_timeout = '5m' предпочтительнее, так как обеспечивает более стабильную и предсказуемую производительность без экстремальных провалов, что критически важно для отзывчивости системы.

Огромная работа проделана. Настроение как на Эльбрусе, летом 2005 года - весь мир на ладони, ты счастлив и нем.