This media is not supported in your browser
VIEW IN TELEGRAM
Анонс следующей статьи:"PG_EXPECTO: Анализ влияния work_mem на операции в памяти СУБД PostgreSQL"
https://dzen.ru/a/aULBju4l2iRx7gNd
Параметр work_mem важен для устранения операций ввода-вывода на диск при выполнении сортировок и хеш-соединений, однако его увеличение не является панацеей для повышения производительности.
Для данной нагрузки и конфигурации достаточно значений в диапазоне 8–16 МБ.
Дальнейший рост производительности должен достигаться за счёт оптимизации других аспектов СУБД и инфраструктуры, таких как настройка блокировок, параллелизма и управления таймаутами.
Параметр work_mem важен для устранения операций ввода-вывода на диск при выполнении сортировок и хеш-соединений, однако его увеличение не является панацеей для повышения производительности.
Для данной нагрузки и конфигурации достаточно значений в диапазоне 8–16 МБ.
Дальнейший рост производительности должен достигаться за счёт оптимизации других аспектов СУБД и инфраструктуры, таких как настройка блокировок, параллелизма и управления таймаутами.
Дзен | Статьи
(ложный прогноз)PG_EXPECTO- work_mem: мифы и реальность производительности PostgreSQL
Статья автора «Postgres DBA» в Дзене ✍: Проанализировать влияние увеличения параметра work_mem, на производительность СУБД и метрики инфраструктуры, для заданного характера нагрузки .
1. Цель и гипотеза
· Цель: Определить оптимальное значение параметра checkpoint_timeout для конфигурации 8 CPU / 8 GB RAM под смешанной OLTP-нагрузкой (SELECT/INSERT/UPDATE/DELETE) с варьируемой интенсивностью (5-22 конкурентных соединения на тип запроса), обеспечивающее максимальную общую пропускную способность (TPS) и минимальную среднюю задержку (latency).
· Основная гипотеза: Существует нелинейная зависимость между checkpoint_timeout и производительностью. При увеличении значения от минимального (5 мин) производительность будет расти, достигнет «плато» (оптимальный диапазон), после чего либо стабилизируется, либо начнёт снижаться из-за чрезмерно долгих и интенсивных операций записи во время контрольной точки. Гипотеза для проверки: оптимальный диапазон лежит между 10 и 45 минутами.
· Цель: Определить оптимальное значение параметра 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' предпочтительнее, так как обеспечивает более стабильную и предсказуемую производительность без экстремальных провалов, что критически важно для отзывчивости системы.
This media is not supported in your browser
VIEW IN TELEGRAM
Огромная работа проделана. Настроение как на Эльбрусе, летом 2005 года - весь мир на ладони, ты счастлив и нем.
Методика , составляющая фундамент pg_hazel и pg_expecto позволяет не только проводить эксперименты и исследования, но и выявлять архитектурные проблемы СУБД в ходе анализа инцидента производительности
https://dzen.ru/a/aUpKleHCIwckc8PH
https://dzen.ru/a/aUpKleHCIwckc8PH
Дзен | Статьи
База данных в тисках: как неоптимальные настройки убивают производительность
Статья автора «Postgres DBA» в Дзене ✍: GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL Представьте мощный спортивный...
История о том, как слабая инфраструктура и ошибки в конфигурации СУБД приводят к неэффективному использованию огромных вычислительных ресурсов CPU и RAM.
https://dzen.ru/a/aUkvdCSl9Q6cPjqs
https://dzen.ru/a/aUkvdCSl9Q6cPjqs
Дзен | Статьи
Прорыв сквозь узкое место: Как раскрыть мощь современного сервера PostgreSQL
Статья автора «Postgres DBA» в Дзене ✍: Представьте мощный сервер с сотнями ядер и терабайтами памяти, который едва справляется с нагрузкой. Парадокс?
В мире настройки PostgreSQL, как и в автоспорте, не существует единой идеальной стратегии для всех трасс. Выбор интервала контрольных точек (checkpoint_timeout) — это ваш пит-стоп: можно заезжать часто для максимальной скорости на прямых, но рискуя потерять время на самом заезде, или реже — для стабильного и предсказуемого ритма всей гонки. Всё зависит от типа «трассы» — характера нагрузки на вашу базу данных.
https://dzen.ru/a/aU-4l9AcUR5e2_nt
https://dzen.ru/a/aU-4l9AcUR5e2_nt
Дзен | Статьи
Анализ влияния checkpoint_timeout на производительность СУБД PostgreSQL в зависимости от типа нагрузки.
Статья автора «Postgres DBA» в Дзене ✍: GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL В мире настройки PostgreSQL, как и в...