На основе детального сравнительного анализа двух экспериментов по оптимизации подсистемы ввода-вывода (IO) для PostgreSQL, был получен ключевой и несколько неожиданный вывод. Эксперименты по настройке параметров отложенной записи (vm.dirty_ratio) и выбору IO-планировщика (deadline) показали, что само по себе тонкое регулирование дисковых операций не является решением фундаментальной проблемы производительности в данной системе. Несмотря на некоторые изменения в метриках (рост IOPS, увеличение задержек), основное узкое место сместилось в сторону процессорных ресурсов (CPU), блокировок и настроек параллелизма внутри СУБД. Этот отчёт наглядно иллюстрирует важность комплексной диагностики: прежде чем оптимизировать диск, стоит убедиться, что проблема действительно в нём.
GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL
Глоссарий терминов | Postgres DBA | Дзен
Рекомендации по изменению параметров ОС
Эксперимент-2: vm.dirty_ratio/vm.dirty_background_ratio
Эксперимент-3(Параметры IO-планировщика)
Deadline
Планировщик ввода-вывода (I/O scheduler) в ядре Linux, который устанавливает предельный срок на обслуживание запросов. Задача — минимизировать задержки ввода-вывода, обеспечить доступ процесса к запрашиваемому дисковому устройству.
Текущее значение:
- cat /sys/block/vdd/queue/scheduler
- cat /sys/block/vdc/queue/scheduler
# cat /sys/block/vdd/queue/scheduler
[none] mq-deadline kyber bfq
# cat /sys/block/vdc/queue/scheduler
[none] mq-deadline kyber bfq
Изменение:
- echo deadline > /sys/block/vdd/queue/scheduler
- echo deadline > /sys/block/vdc/queue/scheduler
# echo deadline > /sys/block/vdd/queue/scheduler
# echo deadline > /sys/block/vdc/queue/scheduler
You have mail in /var/spool/mail/root
# cat /sys/block/vdd/queue/scheduler
[mq-deadline] kyber bfq none
# cat /sys/block/vdc/queue/scheduler
[mq-deadline] kyber bfq none
Основание:
deadline уменьшает задержки для операций чтения, что критично при OLAP-нагрузке.
Ожидаемый эффект:
Улучшение времени отклика на чтение, снижение r_await.
Отчет по анализу производительности подсистемы IO
1. Общая характеристика системы
Период анализа: 05.01.2026 15:02 – 16:51
Основные устройства хранения:
- vdd (100 ГБ, LVM /data) — PGDATA
- vdc (50 ГБ, LVM /wal) — WAL
Тип нагрузки:
- На vdd: OLAP-сценарий (чтение преобладает над записью, соотношение ~2.9:1)
- На vdc: Смешанная нагрузка (преобладает запись)
2. Критические проблемы производительности
Устройство vdd:
- 100% утилизация (%util) в течение всего периода
- Высокая длина очереди запросов (aqu_sz до 29, всегда >1)
- Более 30% операций записи имеют задержку >5 мс
- Процессы в состоянии D (uninterruptible sleep) часто превышают количество ядер CPU
- Высокий cpu_wa (42–51%) — CPU значительное время ждёт завершения IO
Устройство vdc:
- Проблем не выявлено, все метрики в пределах нормы
3. Анализ корреляций и паттернов нагрузки
На vdd:
- Сильная положительная корреляция между cache и rMB/s (0.7547) — рост чтения приводит к росту использования кэша
- Сильная отрицательная корреляция между cache и wMB/s (-0.8680) — кэш неэффективен для записи
- Высокая корреляция операционной скорости с чтением блоков (0.9143) — скорость приложения напрямую зависит от дискового чтения
На vdc:
- Корреляции слабые или отрицательные, что указывает на сбалансированную или не-IO-ограниченную нагрузку
4. Диагностика узких мест IO
Вывод по диагностике узких мест IO:
- vdd является узким местом — устройство постоянно перегружено, высокая очередь и задержки записи
- Проблема не в пропускной способности диска (отрицательная корреляция speed – MB/s)
- Возможные причины: недостаток RAM для кэширования, неэффективные запросы (seq scan), блокировки СУБД, параметры параллелизма
5. Итоговый вывод по производительности IO
Система испытывает серьёзные проблемы с производительностью IO на основном диске данных (vdd).
Устройство постоянно перегружено, наблюдаются высокие задержки записи и длинные очереди запросов. Это напрямую влияет на производительность приложений, о чём свидетельствует высокий cpu_wa и сильная зависимость скорости операций от дискового чтения.
Рекомендуется срочная оптимизация: увеличение RAM, настройка СУБД и рассмотрение апгрейда дисковой подсистемы. Устройство vdc проблем не вызывает и может оставаться в текущей конфигурации.
Отчет подготовлен на основе данных мониторинга за период 05.01.2026 15:02–16:51
Эксперимент-2 (vm.dirty_ratio/vm.dirty_background_ratio) vs Эксперимент-3(Параметры IO-планировщика)
Операционная скорость
Среднее увеличение операционной скорости в ходе Эсперимента-3 по сравнению с Экпериментом-2 составило 1.77%.
Среднее снижение операционной скорости в ходе Эсперимента-3 по сравнению с Экпериментом-2 составило 3.35% при низкой нагрузке на СУБД.
Среднее увеличение операционной скорости в ходе Эсперимента-3 по сравнению с Экпериментом-2 составило 6.37% при высокой нагрузке на СУБД.
Ожидания СУБД
IOPS
Пропускная способность (MB/s)
Длина очереди (aqu_sz)
Ожидание по чтению
Ожидание по записи
Сравнительный анализ
2.io_performance.txt - Данные по производительности IO в ходе эксперимента-2
3.io_performance.txt - Данные по производительности IO в ходе эксперимента-3
Подготовь итоговый отчет по результатам сравнительного анализа производительности подсистемы IO в ходе экспериментов.
Состав отчета:
**Сравнение критические проблем производительности**
**Сравнительный анализ корреляций и паттернов нагрузки**
**Диагностика метрик IO**
- r_await(ms)
- w_await(ms)
- aqu_sz
- proc_b
- cpu_wa(%)
- Корреляция speed с IOPS
- Корреляция speed с пропускной способностью
- Другие показатели производительности IO
- Вывод по диагностике узких мест IO
**Итоговый вывод по сравнению производительности IO в ходе экспериментов**
1. Сравнение критических проблем производительности
Вывод: Оба эксперимента показывают, что узкое место производительности не в подсистеме IO. Основные проблемы связаны с CPU, блокировками и настройками параллелизма.
2. Сравнительный анализ корреляций и паттернов нагрузки
Вывод:
- В эксперименте 2 наблюдается более выраженная отрицательная корреляция между скоростью и пропускной способностью, что может указывать на системные задержки, не связанные с диском.
- В эксперименте 3 корреляция speed-IOPS стала слабо положительной, что может свидетельствовать о незначительном улучшении отладки IO-планировщика, но проблема остаётся.
3. Диагностика метрик IO
Корреляция speed с IOPS
- Эксперимент 2: Отрицательная (-0.2692) → рост IOPS не улучшает скорость.
- Эксперимент 3: Слабая положительная (+0.1309) → минимальное влияние IOPS на скорость.
Корреляция speed с пропускной способностью
- Оба эксперимента показывают отрицательную корреляцию, что исключает диск как узкое место.
Другие показатели производительности IO
- utilization (%) = 100% в обоих экспериментах → система постоянно занята.
- shared_blks_ показатели схожи, что указывает на одинаковую природу нагрузки (OLTP/OLAP).
Вывод по диагностике узких мест IO
- Задержки на чтение/запись (r_await, w_await) выросли в эксперименте 3, возможно из-за настройки планировщика.
- Очередь (aqu_sz) и количество процессов в ожидании (proc_b) увеличились, что согласуется с гипотезой о блокировках/ожиданиях.
- CPU wait (cpu_wa) остаётся высоким, подтверждая, что CPU — узкое место.
4. Итоговый вывод по сравнению производительности IO в ходе экспериментов
IO не является ограничивающим фактором ни в одном из экспериментов.
Изменение параметров IO (dirty_ratio, планировщик) не привело к значимому улучшению производительности системы.
Нагрузка остаётся CPU-интенсивной с признаками contention (блокировки, ожидания).
Эксперимент 3 показал незначительный рост IOPS и MB/s, но задержки (await) и очередь (aqu_sz) выросли, что может указывать на повышенную конкуренцию за ресурсы.
Заключение: Оба эксперимента подтверждают, что проблема производительности лежит вне подсистемы IO. Требуется углублённый анализ CPU, блокировок и настроек параллелизма для дальнейшей оптимизации.
Итог эксперимента-3 по сравнению с экспериментом-2
Изменение параметров IO-планировщика привело к снижению производительности СУБД при низкой нагрузке и повышению производительности СУБД при высокой нагрузке, при практически неизменном значении ожиданий СУБД.
Эксперимент 3 показал незначительный рост IOPS и MB/s, но задержки (await) и очередь (aqu_sz) выросли, что может указывать на повышенную конкуренцию за ресурсы.