Тема для исследований.
Настройка СУБД PostgreSQL не ограничивается её внутренними параметрами. Ключевым фактором является взаимодействие с операционной системой. В данном отчёте исследуется теоретическое влияние тонкого параметра ядра Linux — vm.vfs_cache_pressure — на эффективность работы PostgreSQL при OLTP, OLAP и смешанных нагрузках.
#postgresql
https://dzen.ru/a/aWx-05OfHlFsNBZM
Настройка СУБД PostgreSQL не ограничивается её внутренними параметрами. Ключевым фактором является взаимодействие с операционной системой. В данном отчёте исследуется теоретическое влияние тонкого параметра ядра Linux — vm.vfs_cache_pressure — на эффективность работы PostgreSQL при OLTP, OLAP и смешанных нагрузках.
#postgresql
https://dzen.ru/a/aWx-05OfHlFsNBZM
PG_EXPECTO 5.1: Влияние vm.dirty_expire_centisecs=3000/1000/2000 на производительность PostgreSQL.
В отчете представлены результаты серии экспериментов по оценке воздействия настройки кэша записи ядра Linux (vm.dirty_expire_centisecs) на производительность СУБД PostgreSQL и дискового массива /data в условиях аналитической (OLAP) нагрузки с преобладанием операций чтения.
#postgresql
https://dzen.ru/a/aWyxxn4qWAPqkmqr
В отчете представлены результаты серии экспериментов по оценке воздействия настройки кэша записи ядра Linux (vm.dirty_expire_centisecs) на производительность СУБД PostgreSQL и дискового массива /data в условиях аналитической (OLAP) нагрузки с преобладанием операций чтения.
#postgresql
https://dzen.ru/a/aWyxxn4qWAPqkmqr
⚠️Теперь любое сравнение или бенчмарк должны в обязательном порядке содержать не только детальную конфигурацию СУБД (версия, размеры буферов, настройки памяти), но и полную информацию о ключевых параметрах операционной системы.⚠️ Без этого контекста результаты тестов теряют объективность и воспроизводимость, так как потенциально скрывают узкие места, обусловленные не СУБД, а её окружением.
#postgresql
https://dzen.ru/a/aW0aXo_lNXVRfObn
#postgresql
https://dzen.ru/a/aW0aXo_lNXVRfObn
В документе представлен план развития инструмента PG_EXPECTO для анализа производительности PostgreSQL, а также перечень исследовательских тем в области статистического анализа СУБД. Особое внимание уделено оценке трудоёмкости реализации каждого направления
#postgresql
https://dzen.ru/a/aW3F-Lz9xAmT0ytZ
Риторические вопросы:
-Почему такая интересная и перспективная тема - мало кому интересна? Вендорам вообще не интересна.
-Как справится с таким огромным объёмом работ одному?
#postgresql
https://dzen.ru/a/aW3F-Lz9xAmT0ytZ
Риторические вопросы:
-Почему такая интересная и перспективная тема - мало кому интересна? Вендорам вообще не интересна.
-Как справится с таким огромным объёмом работ одному?
Анонс исследования: Моделирование OLAP-нагрузки и анализ влияния параметров ОС на производительность СУБД
В рамках цикла материалов по оптимизации инфраструктуры данных представляем методологию создания воспроизводимого тестового сценария pg_expecto.
Цель — генерация контролируемой нагрузки, имитирующей работу аналитических запросов (OLAP) в PostgreSQL.
Созданный сценарий планируется использовать как инструмент для фундаментального исследования. Ключевая научно-практическая задача — количественная оценка влияния конфигурационных параметров операционной системы (ядро Linux, планировщик ввода-вывода, управление памятью) на производительность СУБД.
Особый интерес представляет сравнительный анализ реакции двух принципиально разных типов нагрузки — аналитической (OLAP) и транзакционной (OLTP) — на единые изменения в окружении. Это позволит выявить потенциальные конфликты настроек и найти баланс для гибридных рабочих нагрузок.
В рамках цикла материалов по оптимизации инфраструктуры данных представляем методологию создания воспроизводимого тестового сценария pg_expecto.
Цель — генерация контролируемой нагрузки, имитирующей работу аналитических запросов (OLAP) в PostgreSQL.
Созданный сценарий планируется использовать как инструмент для фундаментального исследования. Ключевая научно-практическая задача — количественная оценка влияния конфигурационных параметров операционной системы (ядро Linux, планировщик ввода-вывода, управление памятью) на производительность СУБД.
Особый интерес представляет сравнительный анализ реакции двух принципиально разных типов нагрузки — аналитической (OLAP) и транзакционной (OLTP) — на единые изменения в окружении. Это позволит выявить потенциальные конфликты настроек и найти баланс для гибридных рабочих нагрузок.
Данный отчет представляет результаты комплексного анализа производительности СУБД PostgreSQL под нагрузкой, имитирующей OLAP.
#postgresql
https://dzen.ru/a/aW-JVhKDJmav3Gcm
#postgresql
https://dzen.ru/a/aW-JVhKDJmav3Gcm
Статья представляет собой глубокий сравнительный анализ паттернов производительности PostgreSQL 17 для двух принципиально разных типов нагрузки — аналитической (OLAP) и транзакционной (OLTP). Исследование проведено с помощью специализированного комплекса pg_expecto, предназначенного для статистического анализа и нагрузочного тестирования. Этот инструмент позволил не только имитировать сценарии, но и выявить тонкие корреляции между внутренними ожиданиями СУБД (DataFileRead, LWLock) и системными метриками (vmstat, iostat). В статье показано, как под нагрузкой ведут себя ключевые показатели: от hit ratio буферного кэша до времени отклика диска, и определены характерные «узкие места» для каждого типа задач.
Это готовый кейс для использования в нагрузочных тестах.
#postgresql
https://dzen.ru/a/aW-cHqWfDwHm_8O5
Это готовый кейс для использования в нагрузочных тестах.
#postgresql
https://dzen.ru/a/aW-cHqWfDwHm_8O5
➡️Анонс: Как настройки ядра Linux влияют на PostgreSQL? Экспериментальное исследование OLTP и OLAP нагрузки
❓Ключевой вопрос: Насколько сильно тонкая настройка операционной системы может ускорить или замедлить работу вашей СУБД PostgreSQL? Я решил проверить это на практике, выбрав четыре критически важных параметра виртуальной памяти Linux.
В предстоящей статье будут представлены результаты серии контролируемых экспериментов, проведенных с помощью комплекса pg_expecto версии 5.2.
Фокус исследования: Сравнение производительности СУБД под OLTP (много коротких транзакций, частое обновление) и OLAP (сложные аналитические запросы, чтение больших объемов данных) типами нагрузки.
Цель — выяснить, как настройки ОС влияют на каждый сценарий.
Что настраивать? Эксперименты затронут ключевые параметры, управляющие работой с «грязной» памятью и кэшем файловой системы:
1️⃣☑️vm.dirty_ratio = 10 — процент памяти, при заполнении которого процессы блокируются для синхронной записи на диск.
2️⃣☑️vm.dirty_background_ratio = 5 — процент памяти, при котором фоновые процессы начинают асинхронную запись «грязных» страниц.
3️⃣vm.swappiness = 10 — склонность ядра к вытеснению страниц из RAM в swap (меньше значение — меньше свапим).
4️⃣vm.vfs_cache_pressure = 50 — тенденция к reclaim (освобождению) кэша inode и dentry (выше значение — агрессивнее очистка).
📋План экспериментов: Всего запланировано 8 тестов, что позволит оценить как индивидуальное, так и совокупное влияние тюнинга:
🔺Базовый замер (дефолтные настройки ОС) для OLTP и OLAP.☑️
🔺Последовательное включение каждого из четырех параметров по отдельности.
🔺Финальный тест со всеми четырьмя настроенными параметрами одновременно.
Что можно будет узнать из статьи:
1️⃣Конкретное влияние каждого параметра (dirty_ratio, swappiness и т.д.) на скорость отклика транзакций (tps) и время выполнения аналитических запросов (latency).
2️⃣Рекомендации по оптимальной конфигурации ОС для чисто OLTP, чисто OLAP и гибридных нагрузок.
3️⃣Практические выводы: стоит ли углубляться в тонкую настройку ядра или «дефолты» уже достаточно хороши?
4️⃣Оценку эффективности инструмента pg_expecto для проведения подобных исследований.
Следите за публикацией, где будет представлена детальная методология, графики сравнения производительности и готовые конфигурации для ваших серверов.
💥Результаты могут удивить!
#PostgreSQL #Производительность #Тюнинг #Linux #OLTP #OLAP #Эксперимент #БазыДанных
❓Ключевой вопрос: Насколько сильно тонкая настройка операционной системы может ускорить или замедлить работу вашей СУБД PostgreSQL? Я решил проверить это на практике, выбрав четыре критически важных параметра виртуальной памяти Linux.
В предстоящей статье будут представлены результаты серии контролируемых экспериментов, проведенных с помощью комплекса pg_expecto версии 5.2.
Фокус исследования: Сравнение производительности СУБД под OLTP (много коротких транзакций, частое обновление) и OLAP (сложные аналитические запросы, чтение больших объемов данных) типами нагрузки.
Цель — выяснить, как настройки ОС влияют на каждый сценарий.
Что настраивать? Эксперименты затронут ключевые параметры, управляющие работой с «грязной» памятью и кэшем файловой системы:
1️⃣☑️vm.dirty_ratio = 10 — процент памяти, при заполнении которого процессы блокируются для синхронной записи на диск.
2️⃣☑️vm.dirty_background_ratio = 5 — процент памяти, при котором фоновые процессы начинают асинхронную запись «грязных» страниц.
3️⃣vm.swappiness = 10 — склонность ядра к вытеснению страниц из RAM в swap (меньше значение — меньше свапим).
4️⃣vm.vfs_cache_pressure = 50 — тенденция к reclaim (освобождению) кэша inode и dentry (выше значение — агрессивнее очистка).
📋План экспериментов: Всего запланировано 8 тестов, что позволит оценить как индивидуальное, так и совокупное влияние тюнинга:
🔺Базовый замер (дефолтные настройки ОС) для OLTP и OLAP.☑️
🔺Последовательное включение каждого из четырех параметров по отдельности.
🔺Финальный тест со всеми четырьмя настроенными параметрами одновременно.
Что можно будет узнать из статьи:
1️⃣Конкретное влияние каждого параметра (dirty_ratio, swappiness и т.д.) на скорость отклика транзакций (tps) и время выполнения аналитических запросов (latency).
2️⃣Рекомендации по оптимальной конфигурации ОС для чисто OLTP, чисто OLAP и гибридных нагрузок.
3️⃣Практические выводы: стоит ли углубляться в тонкую настройку ядра или «дефолты» уже достаточно хороши?
4️⃣Оценку эффективности инструмента pg_expecto для проведения подобных исследований.
Следите за публикацией, где будет представлена детальная методология, графики сравнения производительности и готовые конфигурации для ваших серверов.
💥Результаты могут удивить!
#PostgreSQL #Производительность #Тюнинг #Linux #OLTP #OLAP #Эксперимент #БазыДанных
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