В ходе экспериментов по оптимизации подсистемы ввода-вывода была проанализирована работа системы под нагрузкой OLAP. Основное внимание уделялось настройкам ядра Linux (vm.dirty_ratio и vm.dirty_background_ratio), влияющим на механизм отложенной записи на диск. Результаты показали, что, несмотря на некоторые улучшения в операционной скорости, корневые проблемы производительности связаны не с дисковыми операциями, а с высокой нагрузкой на процессор и внутренними блокировками СУБД. Данная статья суммирует ключевые выводы и предоставляет рекомендации для дальнейшей оптимизации.
GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL
Глоссарий терминов | Postgres DBA | Дзен
Базовые показатели IO
Рекомендации по изменению параметров ОС.
Эксперимент-2(vm.dirty_ratio/vm.dirty_background_ratio)
vm.dirty_ratio
Параметр ядра Linux, который указывает, какой процент общей оперативной памяти должен быть занят, чтобы процесс, ведущий запись данных на диск, инициировал запись кэшированных данных непосредственно на жёсткий диск.
vm.dirty_background_ratio
Параметр ядра операционной системы Linux, который указывает процент памяти, заполненной «грязными» страницами (изменёнными, но ещё не записанными на диск).
Текущее значение:
- sysctl vm.dirty_ratio
- sysctl vm.dirty_background_ratio
# sysctl vm.dirty_ratio
vm.dirty_ratio = 30
# sysctl vm.dirty_background_ratio
vm.dirty_background_ratio = 10
Изменение:
- sysctl -w vm.dirty_ratio=10
- sysctl -w vm.dirty_background_ratio=5
# sysctl -w vm.dirty_ratio=10
vm.dirty_ratio = 10
# sysctl -w vm.dirty_background_ratio=5
vm.dirty_background_ratio = 5
# sysctl vm.dirty_ratio
vm.dirty_ratio = 10
# sysctl vm.dirty_background_ratio
vm.dirty_background_ratio = 5
Основание
Снижает объем «грязных» страниц в памяти перед записью на диск, уменьшая пиковую нагрузку на IO.
Ожидаемый эффект
Более равномерная запись, снижение пикового времени ожидания записи.
Отчет по анализу производительности подсистемы IO
1. Общая характеристика системы
- Период анализа: 2026-01-05 09:44 – 2026-01-05 11:34 (2 часа)
- Основные устройства хранения:
- vdd (/data, 99 ГБ) — основное хранилище данных
- vdc (/wal, 49 ГБ) — журнал предзаписи
- vda — системный диск
- vdb (/log) — диск для логов
- Тип нагрузки: OLAP (аналитическая), подтверждается высоким соотношением операций чтения к записи (2.88:1)
2. Критические проблемы производительности
- Диск vdd постоянно загружен на 100% (%util = 100)
- Высокое время ожидания CPU для IO (wa > 10% в 100% наблюдений)
- Длина очереди запросов (aqu_sz) постоянно > 1 (до 23)
- Более 27% наблюдений — время ответа на запись > 5 мс (w_await)
- Процессы в состоянии uninterruptible sleep (proc_b) превышают количество ядер CPU (до 13 при 8 ядрах)
- Высокая корреляция между использованием буферной памяти и операциями записи (buff – w/s = 0.74)
3. Анализ корреляций и паттернов нагрузки
- Корреляция wa – util отрицательная (−0.36), что говорит о том, что ожидание CPU не напрямую связано с загрузкой диска
- Корреляция buff – w/s высокая (0.74), что указывает на неэффективное использование буферной памяти для снижения нагрузки на запись
- Корреляция speed – IOPS отрицательная (−0.27), производительность не ограничена IOPS
- Корреляция speed – MB/s отрицательная (−0.84), пропускная способность диска не является узким местом
4. Диагностика узких мест IO
Вывод по диагностике:
Узкое место — не в пропускной способности диска или IOPS, а в высокой загрузке CPU из-за ожидания IO и, возможно, в блокировках на уровне СУБД или приложений. Система работает в режиме OLAP с высокой нагрузкой на чтение, но диск vdd не справляется с потоком запросов.
5. Итоговый вывод по производительности IO
Подсистема IO находится под критической нагрузкой, особенно диск vdd.
Основная проблема — не диски, а CPU, который простаивает в ожидании IO, что указывает на неэффективное использование памяти, высокую нагрузку на чтение и возможные блокировки на уровне приложения/СУБД.
Эксперимент-1(Базовые показатели) vs Эксперимент-2 (vm.dirty_ratio/vm.dirty_background_ratio)
Операционная скорость
Среднее увеличение операционной скорости в ходе Эсперимента-2 составило 10.27%.⬆️
Ожидания СУБД
IOPS
Среднее увеличение IOPS в ходе Эсперимента-2 составило 3.51%.
Пропускная способность (MB/s)
Среднее увеличение MB/s в ходе Эсперимента-2 составило 5.56%.
Длина очереди (aqu_sz)
Ожидание по чтению
Ожидание по записи
Промпт
1.io_performance.txt - Данные по производительности IO в ходе эксперимента-1
2.io_performance.txt - Данные по производительности IO в ходе эксперимента-2
Подготовь итоговый отчет по результатам сравнительного анализа производительности подсистемы IO в ходе экспериментов.
Состав отчета:
**Сравнение критические проблем производительности**
**Сравнительный анализ корреляций и паттернов нагрузки**
**Диагностика метрик IO**
- r_await(ms)
- w_await(ms)
- aqu_sz
- proc_b
- cpu_wa(%)
- Корреляция speed с IOPS
- Корреляция speed с пропускной способностью
- Другие показатели производительности IO
- Вывод по диагностике узких мест IO
**Итоговый вывод по сравнению производительности IO в ходе экспериментов**
1. Сравнение критических проблем производительности
Вывод: В Эксперименте-2 проблема с CPU стала ещё более явной (ALARM), что может указывать на усиление нагрузки на процессор из-за изменений в настройках отложенной записи.
2. Сравнительный анализ корреляций и паттернов нагрузки
Вывод: Настройки vm.dirty_ratio/vm.dirty_background_ratio привели к усилению отрицательной корреляции между скоростью операции и пропускной способностью диска, что ещё больше подтверждает, что проблема не в IO, а в других подсистемах (CPU, блокировки, память).
3. Диагностика метрик IO
Вывод по диагностике узких мест IO:
- Задержки записи (w_await) немного выросли, что может быть связано с настройками отложенной записи.
- Длина очереди (aqu_sz) увеличилась, что указывает на большее накопление запросов.
- CPU wait (cpu_wa) остаётся высоким, что подтверждает гипотезу о CPU как узком месте.
- Пропускная способность и IOPS не изменились кардинально, что говорит об отсутствии ограничений со стороны диска.
4. Итоговый вывод по сравнению производительности IO в ходе экспериментов
IO не является узким местом ни в одном из экспериментов. Отрицательные и слабые корреляции с операционной скоростью подтверждают, что производительность ограничена не диском, а другими компонентами (CPU, блокировки, память, настройки СУБД).
Настройки vm.dirty_ratio/vm.dirty_background_ratio:
- Не улучшили производительность IO.
- Привели к усилению отрицательной корреляции speed-MB/s.
- Возможно, увеличили нагрузку на CPU из-за изменения паттерна записи.
Заключение:
Эксперимент-2 подтвердил выводы Эксперимента-1: проблема производительности лежит вне подсистемы IO.
Изменения в настройках отложенной записи не привели к улучшениям и даже усилили признаки CPU-ограничения.
Далее следует сосредоточиться на оптимизации CPU и работы СУБД.
Итог эксперимента-2
Изменение настроек vm.dirty_ratio/vm.dirty_background_ratio в целом оказало положительное влияние на производительность СУБД , однако существенного влияния на производительности дисковой подсистемы IO не было достигнуто.