Эксперимент проводился с целью проверки гипотезы о том, что уменьшение времени хранения «грязных» данных в памяти с 30 до 10 секунд позволит снизить нагрузку на подсистему ввода-вывода и улучшить отклик системы.
Глоссарий терминов | Postgres DBA | Дзен
GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL
Теоретическая часть
vm.dirty_expire_centisecs = 1000 (10 секунд):
- Уменьшает максимальное время хранения "грязных" данных в 3 раза
- Позволяет более равномерно распределить запись на диск
- Снижает риск накопления большого объема данных для сброса
Ожидаемый эффект:
- Снижение wa (I/O wait) с текущих 50-71% до 20-40%
- Уменьшение процессов в состоянии D с 16 до 5-8
- Более стабильная производительность без резких провалов
- Улучшение времени отклика операций чтения
При слишком агрессивных настройках может возрасти нагрузка на диск из-за более частых мелких записей. Если это произойдет, увеличьте значение до 1500-2000.
Данные настройки оптимизируют баланс между отзывчивостью системы и эффективностью использования дискового ввода-вывода для вашего конкретного OLAP-сценария.
Практическая часть: Экспериментальная проверка влияния vm.dirty_expire_centisecs=1000
Важное изменение в версии 5.1⚠️
Изменены тестовые сценарии scenario-2 и scenario-3.
scenario-2 (INSERT)
scenario-3 (UPDATE)
scenario-1 (SELECT) - без изменений
Веса тестовых сценариев и параметры нагрузочного тестирования
# Веса сценариев по умолчанию
scenario1 = 0.7
scenario2 = 0.2
scenario3 = 0.1
Измененные параметры операционной системы ⚠️
1️⃣Общие параметры производительности
vm.dirty_ratio = 10
vm.dirty_background_ratio = 5
2️⃣Параметры IO-планировщика
[mq-deadline] kyber bfq none
3️⃣Настройки кэширования и буферизации
vm.vfs_cache_pressure = 50
4️⃣Оптимизация параметров файловой системы
/dev/mapper/vg_data-LG_data on /data type ext4 (rw,noatime,nodiratime)
5️⃣Изменение размера буферов для операций с блочными устройствами
read_ahead_kb = 256
Нагрузка на СУБД в ходе экспериментов
Изменение vm.swappiness
# sysctl vm.dirty_expire_centisecs
sysctl vm.dirty_writeback_centisecs
sysctl vm.dirty_background_ratio
sysctl vm.dirty_ratio
vm.dirty_expire_centisecs = 3000
vm.dirty_writeback_centisecs = 500
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10
# sysctl -w vm.dirty_expire_centisecs=1000
vm.dirty_expire_centisecs = 1000
# sysctl vm.dirty_expire_centisecs vm.dirty_writeback_centisecs vm.dirty_background_ratio vm.dirty_ratio
vm.dirty_expire_centisecs = 1000
vm.dirty_writeback_centisecs = 500
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10
Эксперимент-1 ( vm.dirty_expire_centisecs = 3000 )
Эксперимент-2 (vm.dirty_expire_centisecs = 1000)
Корреляционный анализ производительности и ожиданий СУБД
Операционная скорость
Среднее уменьшение операционной скорости в Эксперименте-2 (vm.dirty_expire_centisecs = 1000) составило 7.14%
Ожидания СУБД
Среднее увеличение ожиданий в Эксперименте-2 (vm.dirty_expire_centisecs = 1000) составило 0.8%
Производительность подсистемы IO
Важно - главный предварительный итог
Изменение параметра vm.dirty_expire_centisecs = 1000 практически не оказывает влияния на метрики производительности подсистемы IO.
IOPS (Производительность IO)
Среднее уменьшение производительности IO в Эксперименте-2 (vm.dirty_expire_centisecs = 1000) составило 1.87%
MB/s (Пропускная способность IO)
Среднее уменьшение пропускной способности IO в Эксперименте-2 (vm.dirty_expire_centisecs = 1000) составило 3.95%
Сравнительный анализ производительности и ожиданий СУБД и метрик vmstat
settings.txt - конфигурация СУБД и инфраструктуры
1.summary.txt - показатели производительности СУБД и vmstat в ходе эксперимента-1
2.summary.txt - показатели производительности СУБД и vmstat в ходе эксперимента-2
Проанализируй данные по метрикам производительности и ожиданий СУБД , метрикам инфраструктуры vmstat.
Подготовь сравнительный итоговый отчет по результатам анализа производительности СУБД и инфраструктуры.
Подготовь итоговый вывод о влиянии значения параметра vm.dirty_expire_centisecs на производительности СУБД и инфраструктуры для данного характера нагрузки и заданных параметров СУБД и операционной системы.
Исключи из отчета рекомендации по оптимизации.
Для построения отчета используй списки , а не таблицы
Конфигурация инфраструктуры и СУБД (одинаковая для обоих экспериментов)
- CPU: 8 ядер, архитектура x86_64
- RAM: 7.5 GB
- Дисковая подсистема:
Данные: 100 GB (vdd → /data)
WAL: 50 GB (vdc → /wal) - PostgreSQL: максимальное количество соединений — 1000
- Нагрузка: три сценария (scenario1, scenario2, scenario3) в базе данных pgbench_db
Сравнение метрик производительности СУБД
1. Операционная скорость (SPEED)
- Эксперимент-1 (3000):
Начало: ~479 430
Пик: 611 850
Конец: 451 528
Угол наклона регрессии: -23.65 (снижение) - Эксперимент-2 (1000):
Начало: ~495 134
Пик: 558 334
Конец: 471 215
Угол наклона регрессии: -28.66 (более крутое снижение)
Вывод: В эксперименте-2 пиковая производительность ниже, а снижение скорости происходит более выраженно.
2. Ожидания СУБД (WAITINGS)
- Эксперимент-1:
Начало: 25 384 событий ожидания
Конец: 78 773 событий ожидания
Угол наклона: +43.62 (рост) - Эксперимент-2:
Начало: 25 774 событий ожидания
Конец: 80 669 событий ожидания
Угол наклона: +43.64 (аналогичный рост)
Вывод: Оба эксперимента демонстрируют практически одинаковый рост ожиданий СУБД.
3. Корреляция SPEED — WAITINGS
- Эксперимент-1: -0.64 (умеренная отрицательная корреляция)
- Эксперимент-2: -0.72 (более сильная отрицательная корреляция)
Вывод: Во втором эксперименте связь между ростом ожиданий и снижением производительности выражена сильнее.
Сравнение типов ожиданий
1. Основной тип ожиданий (в обоих экспериментах)
- IO-ожидания: более 99% всех ожиданий
- Основное событие: DataFileRead (чтение данных с диска)
2. Различия в типах ожиданий
- Эксперимент-1: только IO-ожидания
- Эксперимент-2: появляются LWLock-ожидания (XidGen, BufferContent, ProcArray), но их доля незначительна (~0.4% от всех ожиданий)
Вывод: Структура ожиданий практически идентична, основной проблемой в обоих случаях являются операции чтения с диска.
Сравнение метрик инфраструктуры (vmstat)
1. Ожидание ввода-вывода (wa)
- Эксперимент-1: 50-71% времени CPU в состоянии ожидания IO
- Эксперимент-2: 50-73% времени CPU в состоянии ожидания IO
2. Процессы в состоянии непрерываемого сна (b)
- Эксперимент-1: 5-16 процессов
- Эксперимент-2: 5-15 процессов
3. Корреляция IO-ожиданий СУБД и метрик vmstat
Оба эксперимента показывают очень высокую корреляцию:
- IO-wa: 0.94 (Эксп-1) vs 0.96 (Эксп-2)
- IO-b: 0.98 (Эксп-1) vs 0.97 (Эксп-2)
4. Использование памяти
- Свободная RAM: менее 5% во всех наблюдениях в обоих экспериментах
- Свопинг: отсутствует в обоих случаях
5. Коэффициент чтения/записи
- Эксперимент-1: 2.91 (прочитано блоков в 2.9 раза больше, чем записано)
- Эксперимент-2: 2.80 (аналогичное соотношение)
Вывод: Оба эксперимента демонстрируют схожую картину нагрузки на инфраструктуру с доминированием операций чтения.
Итоговый вывод о влиянии vm.dirty_expire_centisecs
На производительность СУБД
Уменьшение параметра с 3000 до 1000 не привело к улучшению производительности.
Напротив:
- Пиковая производительность в эксперименте-2 ниже (558,334 vs 611,850 операций/сек)
- Снижение производительности происходит более выраженно (угол наклона -28.66 vs -23.65)
- Корреляция между ожиданиями и производительностью сильнее (-0.72 vs -0.64)
На ожидания СУБД
Оба значения параметра демонстрируют одинаковую динамику роста ожиданий с течением времени.
На типы ожиданий
При значении 1000 появляются незначительные LWLock-ожидания, которые отсутствовали при значении 3000.
На нагрузку на инфраструктуру
Оба эксперимента показывают идентичную картину:
- Высокая нагрузка на подсистему ввода-вывода (50-73% времени ожидания)
- Большое количество процессов в состоянии непрерываемого сна
- Очень высокая корреляция между IO-ожиданиями СУБД и метриками инфраструктуры
- Критически низкий уровень свободной оперативной памяти
На характер нагрузки: В обоих случаях наблюдается OLAP-сценарий с преобладанием операций чтения над записью (соотношение ~2.8:1).
Общий вывод
Для данной конфигурации СУБД и характера нагрузки (доминирование операций чтения, OLAP-сценарий) изменение параметра vm.dirty_expire_centisecs с 3000 на 1000 не привело к улучшению производительности.
Оба значения параметра демонстрируют схожую картину ограничения производительности подсистемой ввода-вывода.
Анализ производительности IO для файловой системы /data
settings.txt - конфигурация СУБД и инфраструктуры
1.io_performance.txt - показатели производительности IO в ходе эксперимента-1
2.io_performance.txt - показатели производительности IO в ходе эксперимента-2
Подготовь сравнительный отчет по результатам анализа производительности подсистемы IO в ходе экспериментов для дисковых устройств, используемых для файловой системы /data
**Общая характеристика системы**
- Тип нагрузки
Состав отчета по файловой системе:
**Критические проблемы производительности по файловой системе**
**Анализ корреляций и паттернов нагрузки по файловой системе**
**Диагностика узких мест IO по файловой системе**
- r_await(ms)
- w_await(ms)
- aqu_sz
- proc_b
- cpu_wa(%)
- Корреляция speed с IOPS
- Корреляция speed с пропускной способностью (MB/s)
- Вывод по диагностике узких мест IO
Подготовь итоговый вывод о влиянии значения параметра vm.dirty_expire_centisecs на производительности подсистемы IO для данного характера нагрузки и заданных параметров СУБД и операционной системы.
Исключи из отчета рекомендации по оптимизации.
Для построения отчета используй списки , а не таблицы.
Общая характеристика системы
- Тип нагрузки: OLAP (преобладание операций чтения над записью, соотношение >1.5)
- Параметры экспериментов:
Эксперимент-1: vm.dirty_expire_centisecs = 3000 (30 секунд)
Эксперимент-2: vm.dirty_expire_centisecs = 1000 (10 секунд)
Критические проблемы производительности по файловой системе /data
Общие для обоих экспериментов:
- 100% загрузка устройства (utilization) в течение всего периода наблюдения
- Высокое время ожидания CPU на IO (wa > 10%) в 100% наблюдений
- Глубокая очередь запросов (aqu_sz > 1) в 100% наблюдений
- Сильная корреляция между wa и util (>0.91), что указывает на блокировку процессов из-за ожидания IO
- Процессы в состоянии ожидания IO (proc_b) превышают количество ядер CPU в 25-50% наблюдений
Анализ корреляций и паттернов нагрузки по файловой системе /data
Общие паттерны:
- Высокое соотношение чтения к записи (~2.8-2.9:1), подтверждающее OLAP-характер нагрузки
- Сильная положительная корреляция скорости операций с чтением блоков (~0.96-0.97), что указывает на зависимость производительности от скорости чтения с диска
- Отрицательная корреляция скорости операций с операциями записи, что свидетельствует о незначительном влиянии записи на производительность
- Высокий процент попаданий в кэш shared buffers (~96.6-96.8%)
- Сильная корреляция между попаданиями в кэш и чтением с диска (~0.98-0.99), что указывает на одновременную работу OLTP- и отчетных запросов
Отличия между экспериментами:
- В эксперименте-2 наблюдается более сильная отрицательная корреляция между использованием памяти (buff/cache) и операциями IO
- В эксперименте-2 процент наблюдений с высоким r_await (>5мс) выше (11.0% vs 1.87%)
Диагностика узких мест IO по файловой системе /data
Показатели задержек (await):
- r_await(ms):
Эксперимент-1: 2.0-5.12 мс (максимум)
Эксперимент-2: 1.0-6.78 мс (максимум)
Вывод: В эксперименте-2 наблюдаются более высокие максимальные задержки чтения - w_await(ms):
Эксперимент-1: 1.73-14.91 мс (максимум)
Эксперимент-2: 1.65-15.16 мс (максимум)
Вывод: Задержки записи сопоставимы в обоих экспериментах
Очереди и ожидания:
- aqu_sz (глубина очереди):
Эксперимент-1: 6.53-38.36
Эксперимент-2: 6.32-36.53
Вывод: Глубина очереди стабильно высокая в обоих экспериментах - proc_b (процессы в ожидании IO):
Оба эксперимента: превышение количества ожидающих процессов над числом ядер CPU в 25-50% наблюдений - cpu_wa(%):
Эксперимент-1: 50-71%
Эксперимент-2: 50-73%
Вывод: Ожидание IO занимает более 50% времени CPU в обоих экспериментах
Корреляционные показатели:
- Корреляция speed с IOPS:
Эксперимент-1: -0.7012 (отрицательная)
Эксперимент-2: -0.8087 (отрицательная)
Вывод: Производительность не ограничена IOPS, проблема в других компонентах - Корреляция speed с пропускной способностью (MB/s):
Эксперимент-1: -0.8707 (отрицательная)
Эксперимент-2: -0.8970 (отрицательная)
Вывод: Пропускная способность диска не является ограничивающим фактором
Вывод по диагностике узких мест IO:
- Узкое место производительности не в подсистеме IO
- Отрицательные корреляции speed с IOPS и MB/s указывают на проблемы в других компонентах (CPU, блокировки, ожидания СУБД)
- Высокие значения cpu_wa и глубины очереди свидетельствуют о том, что процессы простаивают в ожидании IO, но это следствие, а не причина проблем
Итоговый вывод о влиянии параметра vm.dirty_expire_centisecs
Сравнительный анализ:
- Изменение параметра с 3000 на 1000 не оказало существенного влияния на ключевые метрики производительности подсистемы IO
- Критические проблемы (100% util, высокий cpu_wa, глубокая очередь) наблюдаются в обоих экспериментах
- Незначительные различия:
В эксперименте-2 немного увеличены максимальные значения r_await
В эксперименте-2 выше процент наблюдений с высоким r_await (>5мс)
В эксперименте-2 несколько снижен процент наблюдений с превышением процессов в ожидании IO над количеством ядер CPU
Заключение:
Для данной конфигурации СУБД и характера нагрузки (OLAP с преобладанием чтения) уменьшение значения vm.dirty_expire_centisecs с 3000 до 1000 не привело к улучшению производительности подсистемы IO.
Проблемы производительности носят системный характер и связаны с несоответствием между:
- Настройками СУБД (высокий параллелизм, агрессивный автовакуум)
- Характером нагрузки (OLAP с интенсивным чтением)
- Возможностями дисковой подсистемы
Параметр vm.dirty_expire_centisecs не является определяющим для производительности в данном сценарии, так как основные узкие места находятся за пределами подсистемы IO.
Результат эксперимента
Не подтверждено в ходе эксперимента:
Ожидаемый эффект:
Снижение wa (I/O wait) с текущих 50-71% до 20-40%
Уменьшение процессов в состоянии D с 16 до 5-8
Более стабильная производительность без резких провалов
Улучшение времени отклика операций чтения
Причина
При слишком агрессивных настройках может возрасти нагрузка на диск из-за более частых мелких записей.
Откат изменений:
sysctl -w vm.dirty_expire_centisecs=3000
sysctl vm.dirty_expire_centisecs
Послесловие
Таким образом, корректировка одного лишь параметра vm.dirty_expire_centisecs не является достаточной для оптимизации производительности в данном сценарии, где ограничения связаны с комплексным взаимодействием СУБД, характера нагрузки и возможностей дисковой подсистемы.