PG_EXPECTO 5.2 : OLTP - влияние dirty_ratio/dirty_background_ratio на производительность СУБД PostgreSQL⁠⁠

Взято с основного технического канала Postgres DBA (возможны правки в исходной статье).

В условиях, когда производительность СУБД упирается в пропускную способность дисковой подсистемы, каждая настройка ОС, влияющая на ввод-вывод, становится критичной. В статье исследуется, может ли агрессивная политика сброса «грязных» страниц памяти (vm.dirty*) смягчить узкое место, или же она лишь усиливает конкуренцию за ресурсы.

Задача

Проанализировать влияние уменьшения значения vm.dirty_ratio/vm.dirty_background_ratio на производительность СУБД при имитации типа нагрузки "OLTP" в ходе нагрузочного тестирования.

Параметры инфраструктуры и базовые значения производительности СУБД

sysctl vm.dirty_expire_centisecs

sysctl vm.dirty_ratio

sysctl vm.dirty_background_ratio

sysctl vm.vfs_cache_pressure

cat /sys/block/vdd/queue/read_ahead_kb

vm.dirty_expire_centisecs = 3000

vm.dirty_ratio = 30

vm.dirty_background_ratio = 10

vm.vfs_cache_pressure = 100

4096

Изменение параметров vm.dirty*

# sysctl -w vm.dirty_ratio=10

vm.dirty_ratio = 10

# sysctl -w vm.dirty_background_ratio=5

vm.dirty_background_ratio = 5

Корреляционный анализ производительности и ожиданий СУБД

Операционная скорость

Среднее снижение операционной скорости, при изменении параметров vm.dirty_ratio/vm.dirty_background_ratio составило 1.33%

Ожидания СУБД

Среднее снижение ожиданий СУБД , при изменении параметров vm.dirty_ratio/vm.dirty_background_ratio составило 0.26%

Сравнительный отчет по нагрузочному тестированию: BASELINE vs vm.dirty*

1. Общая характеристика системы в экспериментах

• Тип нагрузки: OLTP (оперативная обработка транзакций).

• Конфигурация СУБД PostgreSQL:
  Версия: PostgreSQL 17.
  Общие буферы (shared_buffers): 4 ГБ.
  Рабочая память (work_mem): 32 МБ.
  Максимальное количество соединений: 1000.
  Настройки autovacuum агрессивные (интервал 1 секунда, масштабный коэффициент 0.01).

• Аппаратная конфигурация:
  CPU: 8 ядер (Intel Xeon Skylake).
  RAM: 8 ГБ.
  Дисковая подсистема: отдельные разделы для данных (/data, 100 ГБ), WAL (/wal, 50 ГБ), логов (/log, 30 ГБ).

2. Сравнительные паттерны ожиданий и производительности СУБД

Эксперимент 1 (базовые настройки):

• Основной тип ожиданий: IO (DataFileRead), доля 100%.

• Корреляция между общими ожиданиями (WAITINGS) и IO: 1.0 (полная линейная зависимость).

• Производительность (SPEED) слабо коррелирует с ожиданиями (коэффициент 0.05).

• Угол наклона линии регрессии для SPEED: положительный (+17.41), производительность росла.

• Угол наклона для WAITINGS: +43.5, ожидания постепенно увеличивались.

• Hit Ratio shared_buffers: ~90.74%, но кэширование слабо влияет на дисковую нагрузку.

Эксперимент 2 (уменьшенные vm.dirty_*):

• Основной тип ожиданий: IO (DataFileRead), доля 100%.

• Корреляция между WAITINGS и IO: 1.0 (полная линейная зависимость).

• Производительность (SPEED) сильно отрицательно коррелирует с ожиданиями (коэффициент -0.91).

• Угол наклона линии регрессии для SPEED: отрицательный (-40.4), производительность снижалась.

• Угол наклона для WAITINGS: +43.56, ожидания продолжали расти.

• Hit Ratio shared_buffers: ~90.73%, паттерн кэширования аналогичен.

Ключевые отличия:

• Во втором эксперименте наблюдалась сильная отрицательная корреляция между SPEED и WAITINGS, что указывает на более выраженное влияние ожиданий на падение производительности.

• Производительность во втором эксперименте снижалась, в то время как в первом — росла.

3. Сравнительные паттерны показателей vmstat/iostat

Общие для обоих экспериментов:

• Высокий процент ожидания IO (wa >10% в 100% наблюдений).

• Количество процессов в состоянии непрерываемого сна (b) превышало количество ядер CPU в 25-50% наблюдений.

• Сильная корреляция между IO и wa (~0.95), а также между IO и b (~0.97).

• Отсутствие своппинга (si/so = 0).

• Свободная память (free) менее 5% в 100% наблюдений.

• Высокая корреляция переключений контекста (cs) и прерываний (in) (~0.95-0.98).

Эксперимент 1:

• Максимальное значение wa: 69%.

• Максимальное значение b: 14 процессов.

• Корреляция SPEED и shared_blks_read: 0.8937 (сильная).

Эксперимент 2:

• Максимальное значение wa: 70%.

• Максимальное значение b: 14 процессов.

• Корреляция SPEED и shared_blks_read: 0.7063 (высокая, но ниже).

• Корреляция SPEED и shared_blks_write: -0.7101 (умеренная отрицательная).

Ключевые отличия:

• Во втором эксперименте наблюдался более выраженный рост b (процессов, ожидающих IO) и wa (времени ожидания IO).

• Зависимость производительности от операций чтения с диска осталась высокой, но несколько снизилась.

4. Итоговый вывод о характерных паттернах производительности и ожиданий СУБД и показателей vmstat/iostat для экспериментов

Единые паттерны для обоих экспериментов:

• Нагрузка имеет явный IO-бутылочное горлышко, связанное с операциями чтения данных (DataFileRead).

• Система испытывает дефицит оперативной памяти для эффективного кэширования (free <5%, но свопинг отсутствует).

• Высокая конкуренция за дисковые ресурсы приводит к росту процессов в состоянии непрерываемого сна (b) и времени ожидания IO (wa).

• Кэш shared_buffers незначительно снижает дисковую нагрузку, что типично для сценариев, где рабочий набор данных превышает доступную память.

• Нагрузка на CPU (us + sy) не является лимитирующим фактором.

Различия между экспериментами:

• Во втором эксперименте снижение производительности (SPEED) происходило более выраженно и было тесно связано с ростом ожиданий (WAITINGS).

• Уменьшение параметров vm.dirty_* не улучшило ситуацию с IO, а в некоторой степени усилило конкуренцию за запись.

Производительность подсистемы IO

IOPS (Производительность IO)

Среднее снижение IOPS , при изменении параметров vm.dirty_ratio/vm.dirty_background_ratio составило 0.48%

MB/s (Пропуская способность IO)

Среднее снижение пропускной способности , при изменении параметров vm.dirty_ratio/vm.dirty_background_ratio составило 1.34%

Отчет по анализу производительности подсистемы IO для файловой системы /data

Критические проблемы производительности по файловой системе для Эксперимента-1 и Эксперимента-2

Эксперимент-1 (базовые настройки):

• Постоянная 100% загрузка устройства (utilization) во всех наблюдениях

• Очень высокая корреляция между ожиданием IO процессором и загрузкой диска (wa - util: 0.9526)

• Высокая корреляция между объемом памяти для буферов и операциями записи (buff - w/s: 0.8728)

• Очень высокая корреляция между кэшированием и объемом чтения с диска (cache - rMB/s: 0.9545)

• 100% наблюдений с глубиной очереди запросов более 1

• 100% наблюдений с ожиданием IO процессором (wa) более 10%

Эксперимент-2 (уменьшенные vm.dirty параметры):

• Постоянная 100% загрузка устройства (utilization) во всех наблюдениях

• Очень высокая корреляция между ожиданием IO процессором и загрузкой диска (wa - util: 0.8587)

• Слабая/средняя корреляция между буферами и операциями записи (улучшение)

• Очень высокая корреляция между кэшированием и объемом чтения с диска (cache - rMB/s: 0.9827)

• 100% наблюдений с глубиной очереди запросов более 1

• 100% наблюдений с ожиданием IO процессором (wa) более 10%

Анализ корреляций и паттернов нагрузки по файловой системе

Эксперимент-1:

• Сильная прямая зависимость операционной скорости от чтения с диска (0.8937)

• Отрицательная корреляция между операционной скоростью и IOPS (-0.2424)

• Кэширование практически не влияет на дисковую нагрузку (корреляция shared_blks_hit - shared_blks_read: 0.0904)

• Высокий HIT RATIO (90.74%), но низкая эффективность кэширования

Эксперимент-2:

• Сильная прямая зависимость операционной скорости от чтения с диска (0.7063)

• Сильная отрицательная корреляция между операционной скоростью и IOPS (-0.7782)

• Отрицательная корреляция между кэшированием и операциями записи (-0.8629)

• Кэширование практически не влияет на дисковую нагрузку (корреляция shared_blks_hit - shared_blks_read: -0.1094)

Узкие места IO по файловой системе

Эксперимент-1:

• Дисковое устройство является основным узким местом

• Процессы блокируются в ожидании IO (высокий wa, процессы в uninterruptible sleep)

• Неэффективное использование памяти для буферизации и кэширования

• Высокая очередь запросов к диску

Эксперимент-2:

• Дисковое устройство остается основным узким местом

• Процессы продолжают блокироваться в ожидании IO

• Улучшение в корреляциях буферов с операциями записи

• Более выраженная отрицательная корреляция speed-IOPS указывает на дополнительные ограничения не в IO

Характерные паттерны показателей IO

Эксперимент-1:

• Стабильно высокие показатели: utilization=100%, IOPS≈4000, MB/s≈34

• Низкое время отклика на чтение/запись (2-4 мс)

• Постепенный рост длины очереди (aqu_sz: 6→14) и ожидания CPU (wa: 51→69)

• Количество процессов в uninterruptible sleep растет со временем

Эксперимент-2:

• Стабильно высокие показатели: utilization=100%, IOPS≈4000, MB/s≈33-35

• Низкое время отклика на чтение/запись (2-4 мс)

• Постепенный рост длины очереди (aqu_sz: 6→14) и ожидания CPU (wa: 51→70)

• Количество процессов в uninterruptible sleep растет со временем

Сравнение характерных паттернов для Эксперимента-1 и Эксперимента-2

• Оба эксперимента демонстрируют практически идентичные абсолютные показатели производительности IO

• В Эксперименте-2 наблюдается снижение корреляции между буферами и операциями записи

• В Эксперименте-2 усилилась отрицательная корреляция между операционной скоростью и IOPS

• Корреляция между ожиданием IO и загрузкой диска снизилась с 0.9526 до 0.8587

• Корреляция между кэшированием и объемом чтения увеличилась с 0.9545 до 0.9827

• Время отклика на операции чтения/записи осталось низким в обоих случаях

• Паттерн роста длины очереди и ожидания CPU аналогичен в обоих экспериментах

Итоговый вывод о влиянии уменьшения значения vm.dirty_ratio/vm.dirty_background_ratio на производительность IO

Уменьшение параметров vm.dirty_ratio/vm.dirty_background_ratio не привело к существенному улучшению производительности подсистемы IO для данной OLTP-нагрузки.

Основные проблемы производительности сохранились в полном объеме: диск остается постоянно перегруженным (100% utilization), процессы блокируются в ожидании IO, сохраняется высокая очередь запросов. Хотя некоторые корреляционные зависимости изменились (улучшилась корреляция буферов с операциями записи, снизилась корреляция wa-util), это не повлияло на ключевые метрики производительности.

Абсолютные значения IOPS, пропускной способности и времени отклика остались практически идентичными.

Система продолжает демонстрировать паттерны, характерные для дискового узкого места, при этом кэширование и буферизация неэффективно снижают нагрузку на диск в обоих конфигурациях.

Послесловие

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