Найти в Дзене
Postgres DBA

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

В условиях, когда производительность СУБД упирается в пропускную способность дисковой подсистемы, каждая настройка ОС, влияющая на ввод-вывод, становится критичной. В статье исследуется, может ли агрессивная политика сброса «грязных» страниц памяти (vm.dirty*) смягчить узкое место, или же она лишь усиливает конкуренцию за ресурсы. Глоссарий терминов | Postgres DBA | Дзен GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL Проанализировать влияние уменьшения значения 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 # sysctl -w vm.dirty_ratio=10 vm.dirty_ratio = 10 #
Оглавление
Настройка vm.dirty_*: ожидание чуда и суровая реальность метрик.
Настройка vm.dirty_*: ожидание чуда и суровая реальность метрик.

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

Глоссарий терминов | Postgres DBA | Дзен

GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL

Задача

Проанализировать влияние уменьшения значения 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

Тестовый сценарий для имитации нагрузки OLTP

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

# sysctl -w vm.dirty_ratio=10

vm.dirty_ratio = 10

# sysctl -w vm.dirty_background_ratio=5

vm.dirty_background_ratio = 5

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

-2

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

Изменение операционной скорости СУБД в ходе нагрузочного тестирования
Изменение операционной скорости СУБД в ходе нагрузочного тестирования

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

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

Изменение ожиданий СУБД в ходе нагрузочного тестирования
Изменение ожиданий СУБД в ходе нагрузочного тестирования

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

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

settings.txt - конфигурация СУБД и ОС
summary_OLTP.txt - базовые показатели производительности и ожиданий СУБД и метрик vmstat/iostat для типа нагрузки OLTP
summary.OLTP.vm.dirty.txt - показатели производительности и ожиданий СУБД и метрик vmstat/iostat для типа нагрузки OLTP и новых значениях vm.dirty_ratio/vm.dirty_background_ratio
Подготовь сравнительный отчет по нагрузочного тестирования
**Общая характеристика системы в экспериментах**
- Тип нагрузки
**Сравнительные паттерны ожиданий и производительности СУБД**
**Сравнительные паттерны показателей vmstat/iostat**
**Итоговый вывод о характерных паттернах производительности и ожиданий СУБД и показателей vmstat/iostat для экспериментов**
**Итоговый вывод о влиянии уменьшения значения vm.dirty_ratio/vm.dirty_background_ratio на производительность СУБД и паттерны производительности, ожиданий и инфраструктуры**
Исключи рекомендации по оптимизации.
Сформируй отчет используя списки, без использования таблиц.

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

  • Тип нагрузки: OLTP (оперативная обработка транзакций).
  • Конфигурация СУБД PostgreSQL:
  • Версия: PostgreSQL 17.
  • Общие буферы (shared_buffers): 4 ГБ.
  • Рабочая память (work_mem): 32 МБ.
  • Максимальное количество соединений: 1000.
  • Настройки autovacuum- агрессивные.
  • Аппаратная конфигурация:
  • 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

-5
-6

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

Изменение производительности IO(IOPS) в ходе нагрузочного тестирования
Изменение производительности IO(IOPS) в ходе нагрузочного тестирования

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

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

Изменение пропускной способности IO(MB/s) в ходе нагрузочного тестирования
Изменение пропускной способности IO(MB/s) в ходе нагрузочного тестирования

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

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

io_performance_OLTP.txt - показатели производительности IO при базовых значениях (baseline)
io_performance.OLTP.vm.dirty.txt - показатели производительности IO при уменьшении vm.dirty_ratio/vm.dirty_background_ratio
Подготовь отчет по результатам анализа производительности подсистемы IO
для дисковых устройств, используемых для файловых систем /data
**Общая характеристика системы**
- Период анализа
- Основные устройства хранения
- Тип нагрузки
**Сравнительный отчет по производительности IO **
- Критические проблемы производительности по файловой системе для Эксперимента-1 и Эксперимента-2
- Анализ корреляций и паттернов нагрузки по файловой системе для Эксперимента-1 и Эксперимента-2
- Узкие места IO по файловой системе для Эксперимента-1 и Эксперимента-2
- Характерные паттерны показателей IO для Эксперимента-1 и Эксперимента-2
**Сравнение характерных паттернов для Эксперимента-1 и Эксперимента-2**
**Итоговый вывод о влиянии уменьшения значения vm.dirty_ratio/vm.dirty_background_ratio на производительность IO**
Исключи рекомендации по оптимизации.
Сформируй отчет используя списки, без использования таблиц.

Критические проблемы производительности по файловой системе для Эксперимента-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, пропускной способности и времени отклика остались практически идентичными.

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

Послесловие

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