This media is not supported in your browser
VIEW IN TELEGRAM
PostgreSQL. Выжми максимум
Уменьшение параметров грязной памяти — интуитивно понятный шаг для снижения IO-нагрузки. Но что, если он лишь меняет "симптомы", не затрагивая корень проблемы? Итоги нагрузочного тестирования бросают вызов упрощенным подходам к тюнингу.
В статье представлены результаты сравнительного анализа производительности СУБД PostgreSQL под OLAP-нагрузкой. Исследование фокусируется на оценке влияния ключевых параметров виртуальной памяти ядра Linux — vm.dirty_ratio и vm.dirty_background_ratio — на поведение системы, паттерны ожиданий и итоговую эффективность.
#postgresql
https://dzen.ru/a/aXCgSD09TjYLotxM
В статье представлены результаты сравнительного анализа производительности СУБД PostgreSQL под OLAP-нагрузкой. Исследование фокусируется на оценке влияния ключевых параметров виртуальной памяти ядра Linux — vm.dirty_ratio и vm.dirty_background_ratio — на поведение системы, паттерны ожиданий и итоговую эффективность.
#postgresql
https://dzen.ru/a/aXCgSD09TjYLotxM
PG_EXPECTO 5.2 : OLTP - влияние vm.dirty_ratio/vm.dirty_background_ratio на производительность СУБД PostgreSQL.
В условиях, когда производительность СУБД упирается в пропускную способность дисковой подсистемы, каждая настройка ОС, влияющая на ввод-вывод, становится критичной. В статье исследуется, может ли агрессивная политика сброса «грязных» страниц памяти (vm.dirty*) смягчить узкое место, или же она лишь усиливает конкуренцию за ресурсы.
#postgresql
https://dzen.ru/a/aXDGJpuEUwzbZ1EU
В условиях, когда производительность СУБД упирается в пропускную способность дисковой подсистемы, каждая настройка ОС, влияющая на ввод-вывод, становится критичной. В статье исследуется, может ли агрессивная политика сброса «грязных» страниц памяти (vm.dirty*) смягчить узкое место, или же она лишь усиливает конкуренцию за ресурсы.
#postgresql
https://dzen.ru/a/aXDGJpuEUwzbZ1EU
OS Tuning — необходимый третий столп оптимизации производительности PostgreSQL.
Классическая методика оптимизации производительности PostgreSQL традиционно делится на две области: тонкую настройку запросов (SQL Tuning) и регулировку параметров экземпляра СУБД (Instance Tuning). Однако эксперименты, проведенные с помощью инструмента нагрузочного тестирования pg_expecto, выявили системное «узкое место»: даже идеально настроенная СУБД упирается в ограничения, накладываемые конфигурацией операционной системы. Данное эссе обосновывает необходимость выделения «OS Tuning» в самостоятельный, критически важный раздел работ по оптимизации.
#PostgreSQL
https://dzen.ru/a/aXQjhZgFo26ewucW
Классическая методика оптимизации производительности PostgreSQL традиционно делится на две области: тонкую настройку запросов (SQL Tuning) и регулировку параметров экземпляра СУБД (Instance Tuning). Однако эксперименты, проведенные с помощью инструмента нагрузочного тестирования pg_expecto, выявили системное «узкое место»: даже идеально настроенная СУБД упирается в ограничения, накладываемые конфигурацией операционной системы. Данное эссе обосновывает необходимость выделения «OS Tuning» в самостоятельный, критически важный раздел работ по оптимизации.
#PostgreSQL
https://dzen.ru/a/aXQjhZgFo26ewucW
PG_EXPECTO : влияние vm.vfs_cache_pressure на производительность PostgreSQL при нагрузке, имитирующей OLAP (1/3).
Существует дефицит специализированных исследований по тонкой настройке ОС для СУБД. Настоящая работа заполняет этот пробел, предлагая экспериментальный анализ влияния параметра vm.vfs_cache_pressure в Linux на производительность PostgreSQL под синтетической OLAP-нагрузкой.
#PostgreSQL
https://dzen.ru/a/aXRoG7HdGxKVd8gD
Существует дефицит специализированных исследований по тонкой настройке ОС для СУБД. Настоящая работа заполняет этот пробел, предлагая экспериментальный анализ влияния параметра vm.vfs_cache_pressure в Linux на производительность PostgreSQL под синтетической OLAP-нагрузкой.
#PostgreSQL
https://dzen.ru/a/aXRoG7HdGxKVd8gD
PG_EXPECTO : влияние vm.vfs_cache_pressure на производительность PostgreSQL при нагрузке, имитирующей OLAP (2/3).
Данный документ содержит анализ влияния параметра ядра Linux vm.vfs_cache_pressure на производительность СУБД PostgreSQL при имитации OLAP-нагрузки. Исследование фокусируется на системных метриках (I/O, память, CPU) и выявляет оптимальные настройки для заданной конфигурации оборудования.
#PostgreSQL
https://dzen.ru/a/aXR6fc_OSmXLrwBG
Данный документ содержит анализ влияния параметра ядра Linux vm.vfs_cache_pressure на производительность СУБД PostgreSQL при имитации OLAP-нагрузки. Исследование фокусируется на системных метриках (I/O, память, CPU) и выявляет оптимальные настройки для заданной конфигурации оборудования.
#PostgreSQL
https://dzen.ru/a/aXR6fc_OSmXLrwBG
PG_EXPECTO : влияние vm.vfs_cache_pressure на производительность PostgreSQL при нагрузке, имитирующей OLAP (3/3).
В данном анализе исследуется влияние параметра ядра Linux vm.vfs_cache_pressure на производительность дисковой подсистемы под аналитической (OLAP) нагрузкой PostgreSQL. На основе данных нагрузочного тестирования сравнивается три значения параметра (50, 100, 150) с целью выявления оптимальной настройки для сценариев работы с большими объемами данных.
#PostgreSQL
https://dzen.ru/a/aXSI2eZLIC5z93tb
В данном анализе исследуется влияние параметра ядра Linux vm.vfs_cache_pressure на производительность дисковой подсистемы под аналитической (OLAP) нагрузкой PostgreSQL. На основе данных нагрузочного тестирования сравнивается три значения параметра (50, 100, 150) с целью выявления оптимальной настройки для сценариев работы с большими объемами данных.
#PostgreSQL
https://dzen.ru/a/aXSI2eZLIC5z93tb
Итог исследования
Проведённое комплексное исследование убедительно демонстрирует, что параметр ядра Linux vm.vfs_cache_pressure оказывает статистически значимое и многогранное влияние на производительность PostgreSQL при OLAP-нагрузке, имитирующей последовательное чтение больших объёмов данных.
Недостатки тестовой конфигурации: Исследование выявило системные проблемы, общие для всех тестов:
Критически низкий hit ratio shared buffers (55-58%), указывающий на недостаточный объём оперативной памяти для данной рабочей нагрузки.
Постоянно высокий уровень ожидания ввода-вывода (wa > 10%), подтверждающий, что диск является узким местом.
Общие рекомендации для OLAP-нагрузок на PostgreSQL:
Аппаратные улучшения (более быстрые NVMe SSD, увеличение RAM) имеют высший приоритет для снятия выявленных ограничений.
Оптимизация ОС: Уменьшение vm.dirty_* соотношений для снижения латентности записи и увеличение read_ahead_kb для ускорения последовательного чтения.
Оптимизация PostgreSQL: Увеличение shared_buffers, work_mem, effective_cache_size и настройка параметров параллельного выполнения.
Постоянно высокий уровень ожидания ввода-вывода (wa > 10%), подтверждающий, что диск является узким местом.
Критически низкий hit ratio shared buffers (55-58%), указывающий на недостаточный объём оперативной памяти для данной рабочей нагрузки.
Анализ расхождений в рекомендациях: vm.vfs_cache_pressure = 100 vs 150
В исследовании содержится кажущееся противоречие: в Части 2 оптимальным названо значение 100, а в Части 3 — 150. Причина этих разных рекомендаций заключается не в ошибке, а в разном фокусе анализа и приоритетах, которые они отражают. Это наглядная иллюстрация того, что процесс оптимизации — это всегда выбор компромиссного решения из набора альтернатив.
Рекомендация из Части 2: vm.vfs_cache_pressure = 100
Фокус анализа: Общая стабильность системы, поведение процессов, управление памятью и свопом.
Ключевые аргументы:
Стабильность процессов: Отсутствие аномального роста процессов в состоянии D (блокировка).
Управление памятью: Наиболее стабильное и предсказуемое использование свопа (наименьший рост).
Сбалансированность: Умеренные корреляции между метриками, отсутствие экстремальных паттернов.
Компромисс: Оптимальный баланс между удержанием данных в кэше и их своевременным освобождением.
Приоритет: Надёжность и предсказуемость долгосрочной работы системы.
Рекомендация из Части 3: vm.vfs_cache_pressure = 150
Фокус анализа: Максимальная производительность дисковой подсистемы, задержки и пропускная способность.
Ключевые аргументы:
Производительность диска: Наивысшая пропускная способность (137.5 MB/s) и наименьшие задержки чтения (9.8 мс).
Эффективность очереди: Самая короткая очередь запросов к диску, что указывает на более эффективную обработку.
Разгрузка CPU: Наименьшая нагрузка процессора в режиме ожидания I/O (wa).
Механизм: Агрессивное освобождение кэша снижает конкуренцию (contention) за оперативную память.
Приоритет: Максимальная скорость обработки данных и минимизация времени выполнения задач.
Заключительный вывод по выбору значения
Обе рекомендации верны в своих контекстах. Выбор между 100 и 150 — это классический инженерный компромисс между «быстро» и «стабильно».
Для продакшен-среды, где критически важны предсказуемость, стабильность и отсутствие аномалий (внезапные блокировки процессов), следует придерживаться рекомендации vm.vfs_cache_pressure = 100 (или диапазон 90-110).
Для выделенных ETL-задач или пакетной аналитической обработки, где ключевая цель — минимизировать время выполнения и диск является подтверждённым узким местом, можно обоснованно применить значение vm.vfs_cache_pressure = 150 для получения максимальной пропускной способности, отдавая себе отчёт в потенциально возросшей нагрузке на подсистему памяти ядра.
Таким образом, исследование не даёт единственно верного ответа, а предоставляет администратору обоснованный выбор в зависимости от конкретных бизнес-требований и приоритетов, подчёркивая, что эффективная оптимизация — это всегда поиск баланса между конфликтующими целями системы.
Проведённое комплексное исследование убедительно демонстрирует, что параметр ядра Linux vm.vfs_cache_pressure оказывает статистически значимое и многогранное влияние на производительность PostgreSQL при OLAP-нагрузке, имитирующей последовательное чтение больших объёмов данных.
Недостатки тестовой конфигурации: Исследование выявило системные проблемы, общие для всех тестов:
Критически низкий hit ratio shared buffers (55-58%), указывающий на недостаточный объём оперативной памяти для данной рабочей нагрузки.
Постоянно высокий уровень ожидания ввода-вывода (wa > 10%), подтверждающий, что диск является узким местом.
Общие рекомендации для OLAP-нагрузок на PostgreSQL:
Аппаратные улучшения (более быстрые NVMe SSD, увеличение RAM) имеют высший приоритет для снятия выявленных ограничений.
Оптимизация ОС: Уменьшение vm.dirty_* соотношений для снижения латентности записи и увеличение read_ahead_kb для ускорения последовательного чтения.
Оптимизация PostgreSQL: Увеличение shared_buffers, work_mem, effective_cache_size и настройка параметров параллельного выполнения.
Постоянно высокий уровень ожидания ввода-вывода (wa > 10%), подтверждающий, что диск является узким местом.
Критически низкий hit ratio shared buffers (55-58%), указывающий на недостаточный объём оперативной памяти для данной рабочей нагрузки.
Анализ расхождений в рекомендациях: vm.vfs_cache_pressure = 100 vs 150
В исследовании содержится кажущееся противоречие: в Части 2 оптимальным названо значение 100, а в Части 3 — 150. Причина этих разных рекомендаций заключается не в ошибке, а в разном фокусе анализа и приоритетах, которые они отражают. Это наглядная иллюстрация того, что процесс оптимизации — это всегда выбор компромиссного решения из набора альтернатив.
Рекомендация из Части 2: vm.vfs_cache_pressure = 100
Фокус анализа: Общая стабильность системы, поведение процессов, управление памятью и свопом.
Ключевые аргументы:
Стабильность процессов: Отсутствие аномального роста процессов в состоянии D (блокировка).
Управление памятью: Наиболее стабильное и предсказуемое использование свопа (наименьший рост).
Сбалансированность: Умеренные корреляции между метриками, отсутствие экстремальных паттернов.
Компромисс: Оптимальный баланс между удержанием данных в кэше и их своевременным освобождением.
Приоритет: Надёжность и предсказуемость долгосрочной работы системы.
Рекомендация из Части 3: vm.vfs_cache_pressure = 150
Фокус анализа: Максимальная производительность дисковой подсистемы, задержки и пропускная способность.
Ключевые аргументы:
Производительность диска: Наивысшая пропускная способность (137.5 MB/s) и наименьшие задержки чтения (9.8 мс).
Эффективность очереди: Самая короткая очередь запросов к диску, что указывает на более эффективную обработку.
Разгрузка CPU: Наименьшая нагрузка процессора в режиме ожидания I/O (wa).
Механизм: Агрессивное освобождение кэша снижает конкуренцию (contention) за оперативную память.
Приоритет: Максимальная скорость обработки данных и минимизация времени выполнения задач.
Заключительный вывод по выбору значения
Обе рекомендации верны в своих контекстах. Выбор между 100 и 150 — это классический инженерный компромисс между «быстро» и «стабильно».
Для продакшен-среды, где критически важны предсказуемость, стабильность и отсутствие аномалий (внезапные блокировки процессов), следует придерживаться рекомендации vm.vfs_cache_pressure = 100 (или диапазон 90-110).
Для выделенных ETL-задач или пакетной аналитической обработки, где ключевая цель — минимизировать время выполнения и диск является подтверждённым узким местом, можно обоснованно применить значение vm.vfs_cache_pressure = 150 для получения максимальной пропускной способности, отдавая себе отчёт в потенциально возросшей нагрузке на подсистему памяти ядра.
Таким образом, исследование не даёт единственно верного ответа, а предоставляет администратору обоснованный выбор в зависимости от конкретных бизнес-требований и приоритетов, подчёркивая, что эффективная оптимизация — это всегда поиск баланса между конфликтующими целями системы.
Оперативная память — поле битвы между кэшем ОС и буферами СУБД. Параметр vm.vfs_cache_pressure выступает в роли регулятора этого противостояния. В условиях OLAP-нагрузки, где важны и предсказуемость, и скорость последовательного чтения, его выбор неочевиден. Данное исследование измеряет последствия этого выбора и намечает путь к более сбалансированной конфигурации.
#PostgreSQL
https://dzen.ru/a/aXSufvm5HzVxQkfL
#PostgreSQL
https://dzen.ru/a/aXSufvm5HzVxQkfL
Текущая конфигурация сервера PostgreSQL не соответствует профилю OLAP-нагрузки, создавая дисбаланс в использовании памяти и формируя узкое место на подсистеме ввода-вывода. Данный анализ выявляет корень проблем и предлагает путь оптимизации.
Нижеизложенная гипотеза сформирована в результате автоматизированного анализа метрик.
Ключевой принцип: любые рекомендации, полученные с помощью ИИ, сколь бы убедительно они ни были аргументированы, необходимо рассматривать как теоретическую модель.
Её адекватность и применимость доказываются исключительно в ходе контролируемого эксперимента и сравнения показателей «до» и «после».
#PostgreSQL
https://dzen.ru/a/aXW4HcMuW1mIVfhn
Нижеизложенная гипотеза сформирована в результате автоматизированного анализа метрик.
Ключевой принцип: любые рекомендации, полученные с помощью ИИ, сколь бы убедительно они ни были аргументированы, необходимо рассматривать как теоретическую модель.
Её адекватность и применимость доказываются исключительно в ходе контролируемого эксперимента и сравнения показателей «до» и «после».
#PostgreSQL
https://dzen.ru/a/aXW4HcMuW1mIVfhn
👍1
Настоящее исследование осуществлено с применением инструментария pg_expecto, обеспечивающего строгую методологию репрезентативного нагрузочного тестирования. Данный инструмент позволил провести сравнительный анализ двух дискретных конфигураций СУБД PostgreSQL в контролируемых и идентичных условиях, моделирующих устойчивую OLAP-нагрузку. Ниже представлено краткое изложение методологии эксперимента, включая описание стенда, генерации нагрузочного паттерна и ключевых варьируемых параметров, что обеспечивает полную воспроизводимость и верифицируемость полученных результатов. Основной целью являлась эмпирическая проверка гипотезы о влиянии реконфигурации областей памяти (shared_buffers и work_mem) на комплексные показатели производительности системы.
#PostgreSQL
https://dzen.ru/a/aXXqFLVrc2CdQJ0p
#PostgreSQL
https://dzen.ru/a/aXXqFLVrc2CdQJ0p
Анонс.
pg_expecto v6: Анализ dirty-страниц, shared_buffers и памяти в сценариях OLAP/OLTP.
Новая, шестая версия делает мощный скачок в анализе работы с памятью. Основной фокус новой версии - динамика dirty-страниц кэша операционной системы и их влиянии на производительность СУБД PostgreSQL, при имитации аналитической (OLAP) и транзакционной (OLTP) нагрузки.
Что принципиально нового в pg_expecto v6?
Мониторинг Dirty-страниц: Анализ ключевых метрик работы механизма фоновой записи ОС:
· dirty_percent — текущий процент «грязных» страниц в кэше ОС.
· dirty_bg_percent — порог, при превышении которого запускается фоновая запись.
· available_memory — общий контекст доступной памяти.
https://dzen.ru/suite/0c674be0-2dbc-4b73-bed0-3c30593c2ca2
pg_expecto v6: Анализ dirty-страниц, shared_buffers и памяти в сценариях OLAP/OLTP.
Новая, шестая версия делает мощный скачок в анализе работы с памятью. Основной фокус новой версии - динамика dirty-страниц кэша операционной системы и их влиянии на производительность СУБД PostgreSQL, при имитации аналитической (OLAP) и транзакционной (OLTP) нагрузки.
Что принципиально нового в pg_expecto v6?
Мониторинг Dirty-страниц: Анализ ключевых метрик работы механизма фоновой записи ОС:
· dirty_percent — текущий процент «грязных» страниц в кэше ОС.
· dirty_bg_percent — порог, при превышении которого запускается фоновая запись.
· available_memory — общий контекст доступной памяти.
https://dzen.ru/suite/0c674be0-2dbc-4b73-bed0-3c30593c2ca2
Тестирование производительности PostgreSQL часто упирается в вопрос: как система поведёт себя под реальной, смешанной нагрузкой? Методы «на глазок» и разрозненные метрики не дают полной картины. PG_EXPECTO v.6 — инструмент, который целенаправленно создаёт реалистичную имитацию OLTP и OLAP-нагрузки, дополняя её структурированными чек-листами по вводу-выводу и памяти, а также ключевой статистикой по vm_dirty и shared_buffers для глубокой диагностики.
https://dzen.ru/a/aYIY9tsuOVYutPS3
https://dzen.ru/a/aYIY9tsuOVYutPS3
В мире администрирования PostgreSQL данные об ожиданиях (wait events) являются ключевым источником диагностики производительности. Однако отдельные метрики без аналитической обработки создают лишь информационный шум, не отвечая на главный вопрос: какой тип ожиданий действительно определяет общую нагрузку на систему?
Метод «Взвешенной корреляции ожиданий (ВКО)», реализованный в комплексе PG_EXPECTO, основан на серьёзной теоретической базе. Он сочетает корреляционный анализ для оценки силы связи между типом ожиданий и общей нагрузкой с взвешиванием по значимости, учитывающим долю каждого типа. Без этого фундамента метрика оставалась бы просто числом, а не стратегическим инструментом приоритизации.
Именно теория превращает ВКО в точный компас, который позволяет отделить системные узкие места от фонового шума и сфокусироваться на главной причине проблем — будь то ожидания IO, IPC или блокировок.
https://dzen.ru/a/aYS6-FFz2FVr6wG6
Метод «Взвешенной корреляции ожиданий (ВКО)», реализованный в комплексе PG_EXPECTO, основан на серьёзной теоретической базе. Он сочетает корреляционный анализ для оценки силы связи между типом ожиданий и общей нагрузкой с взвешиванием по значимости, учитывающим долю каждого типа. Без этого фундамента метрика оставалась бы просто числом, а не стратегическим инструментом приоритизации.
Именно теория превращает ВКО в точный компас, который позволяет отделить системные узкие места от фонового шума и сфокусироваться на главной причине проблем — будь то ожидания IO, IPC или блокировок.
https://dzen.ru/a/aYS6-FFz2FVr6wG6
📋План работ на следующую неделю:
1️⃣Чек-лист параметров CPU, IO, RAM (Linux , PostgreSQL) для типов нагрузки OLTP/ OLAP - список текущих значений для анализа с помощью нейросети.
2️⃣Дополнить чек-лист RAM анализом корреляции vm_dirty* и метрик vmstat.
3️⃣Дополнить чек-лист IO анализом корреляции shared_buffers и метрик vmstat.
1️⃣Чек-лист параметров CPU, IO, RAM (Linux , PostgreSQL) для типов нагрузки OLTP/ OLAP - список текущих значений для анализа с помощью нейросети.
2️⃣Дополнить чек-лист RAM анализом корреляции vm_dirty* и метрик vmstat.
3️⃣Дополнить чек-лист IO анализом корреляции shared_buffers и метрик vmstat.
Производительность PostgreSQL — это не магия, а результат грамотной настройки множества взаимосвязанных компонентов: от ядра операционной системы до внутренних параметров СУБД. Данный материал представляет собой сжатое, практико-ориентированное руководство, которое систематизирует ключевые настройки для Linux и PostgreSQL. Опираясь на результаты нагрузочного тестирования, мы выделим оптимальные значения для типовой конфигурации сервера и объясним, как они влияют на работу под различными типами нагрузок — OLTP и OLAP.
https://dzen.ru/a/aYbUwvk2nRiCYIqy
https://dzen.ru/a/aYbUwvk2nRiCYIqy
Анализ корреляции между параметрами vm.dirty и метриками vmstat.
Производительность СУБД, особенно такой мощной, как PostgreSQL, напрямую зависит от тонкой настройки не только самой базы данных, но и операционной системы.
https://dzen.ru/a/aYbYr5rF1Gabx4P3
Производительность СУБД, особенно такой мощной, как PostgreSQL, напрямую зависит от тонкой настройки не только самой базы данных, но и операционной системы.
https://dzen.ru/a/aYbYr5rF1Gabx4P3
Анализ эффективности и применимости корреляции метрик shared_buffers PostgreSQL и vmstat.
Совместный анализ метрик буферного кэша PostgreSQL (shared_buffers) и системной статистики (vmstat) позволяет выявлять взаимосвязи между работой СУБД и использованием ресурсов ОС. Это помогает находить узкие места в производительности, такие как нехватка оперативной памяти или перегрузка дисковой подсистемы.
https://dzen.ru/a/aYbbg1VkdAr2LcCm
Совместный анализ метрик буферного кэша PostgreSQL (shared_buffers) и системной статистики (vmstat) позволяет выявлять взаимосвязи между работой СУБД и использованием ресурсов ОС. Это помогает находить узкие места в производительности, такие как нехватка оперативной памяти или перегрузка дисковой подсистемы.
https://dzen.ru/a/aYbbg1VkdAr2LcCm
Тема исследований на ближайшие полгода.
Анализ производительности современных СУБД, таких как PostgreSQL, часто упирается в сложную задачу интерпретации множества взаимосвязанных метрик. Традиционные методы, основанные на выявлении корреляций, не всегда способны ответить на ключевой вопрос: что является причиной, а что — следствием возникающей проблемы?
В контексте поиска более совершенных подходов к диагностике всё большее внимание привлекают методы причинно-следственного анализа, в частности, причинность по Гренджеру (Granger causality). Этот статистический инструмент, применяемый к временным рядам, позволяет с определённой долей уверенности утверждать, предшествует ли изменение одной метрики изменению другой, что является значительным шагом вперёд по сравнению с простой констатацией взаимосвязи.
https://dzen.ru/a/aYgqsVFz2FVrOIbd
Анализ производительности современных СУБД, таких как PostgreSQL, часто упирается в сложную задачу интерпретации множества взаимосвязанных метрик. Традиционные методы, основанные на выявлении корреляций, не всегда способны ответить на ключевой вопрос: что является причиной, а что — следствием возникающей проблемы?
В контексте поиска более совершенных подходов к диагностике всё большее внимание привлекают методы причинно-следственного анализа, в частности, причинность по Гренджеру (Granger causality). Этот статистический инструмент, применяемый к временным рядам, позволяет с определённой долей уверенности утверждать, предшествует ли изменение одной метрики изменению другой, что является значительным шагом вперёд по сравнению с простой констатацией взаимосвязи.
https://dzen.ru/a/aYgqsVFz2FVrOIbd
План работ по реализации причинности по Гренджеру для анализа и оптимизации производительности СУБД PostgreSQL
https://dzen.ru/a/aYwTk2wd009T3nMZ
https://dzen.ru/a/aYwTk2wd009T3nMZ
PG_EXPECTO v.7 : Комплексный статистический анализ ожиданий СУБД PostgreSQL.
Традиционный подход к диагностике производительности PostgreSQL зачастую опирается на эвристики, «типовые чек‑листы» и интуицию администратора. Администратор видит всплеск ожиданий, находит самый массовый тип события и принимает решение: «увеличить shared_buffers» или «выключить параллельные запросы». Такой метод работает в очевидных случаях, но оказывается бессилен, когда система находится в состоянии сложного баланса между разными механизмами, а первопричина торможения скрыта за вторичными эффектами.
https://dzen.ru/a/aY3whK80YmixfEUZ
Традиционный подход к диагностике производительности PostgreSQL зачастую опирается на эвристики, «типовые чек‑листы» и интуицию администратора. Администратор видит всплеск ожиданий, находит самый массовый тип события и принимает решение: «увеличить shared_buffers» или «выключить параллельные запросы». Такой метод работает в очевидных случаях, но оказывается бессилен, когда система находится в состоянии сложного баланса между разными механизмами, а первопричина торможения скрыта за вторичными эффектами.
https://dzen.ru/a/aY3whK80YmixfEUZ