Найти в Дзене
Postgres DBA
64 подписчика

Анализ возможности оптимизации планировщика IO.

5 мин
В мире высоконагруженных СУБД каждый компонент системы требует пристального внимания. Подсистема ввода-вывода (IO) часто становится узким местом, напрямую влияющим на отзывчивость и стабильность работы базы данных. Данный анализ фокусируется на сердце этой подсистемы — планировщике операций ввода-вывода. Мы не просто сравниваем доступные алгоритмы (mq-deadline, kyber, bfq, none), но и проводим детальную оценку их применимости в конкретных условиях: для основного хранилища данных (vdd) и диска журнала транзакций (vdc). Цель — не слепая погоня за новыми технологиями, а взвешенное, обоснованное решение, основанное на анализе нагрузки, характеристик накопителей и архитектурных особенностей PostgreSQL. GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL Глоссарий терминов | Postgres DBA | Дзен vdd (данные): [mq-deadline] kyber bfq none
vdc (журнал): [mq-deadline] kyber bfq none Текущий выбор: mq-deadline на обоих устройст
Оглавление
Оптимизация IO: когда выбор планировщика — это стратегия, а не случайность.
Оптимизация IO: когда выбор планировщика — это стратегия, а не случайность.

В мире высоконагруженных СУБД каждый компонент системы требует пристального внимания. Подсистема ввода-вывода (IO) часто становится узким местом, напрямую влияющим на отзывчивость и стабильность работы базы данных. Данный анализ фокусируется на сердце этой подсистемы — планировщике операций ввода-вывода. Мы не просто сравниваем доступные алгоритмы (mq-deadline, kyber, bfq, none), но и проводим детальную оценку их применимости в конкретных условиях: для основного хранилища данных (vdd) и диска журнала транзакций (vdc). Цель — не слепая погоня за новыми технологиями, а взвешенное, обоснованное решение, основанное на анализе нагрузки, характеристик накопителей и архитектурных особенностей PostgreSQL.

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

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

PG_EXPECTO: Оптимизация подсистемы IO. Эксперимент-3: Параметры IO-планировщика

PG_EXPECTO: Оптимизация подсистемы IO. Эксперимент-3: Параметры IO-планировщика
Postgres DBA5 января

1. Текущая конфигурация планировщиков

vdd (данные): [mq-deadline] kyber bfq none

vdc (журнал): [mq-deadline] kyber bfq none

Текущий выбор: mq-deadline на обоих устройствах.

2. Характеристики доступных планировщиков

mq-deadline (текущий)

  • Принцип работы: Гарантирует максимальное время обслуживания запросов
  • Приоритеты: Чтение над записью (особенно важно для СУБД)
  • Особенности: Использует "deadline" механизм для предотвращения голодания операций
  • Лучше всего для: Смешанных нагрузок, особенно с преобладанием чтения

kyber

  • Принцип работы: Адаптивный планировщик, оптимизированный для SSD/NVMe
  • Особенности: Автоматически настраивает глубину очереди на основе целевых задержек
  • Лучше всего для: Быстрых накопителей (SSD/NVMe) в виртуализированных средах

bfq (Budget Fair Queuing)

  • Принцип работы: Справедливое распределение пропускной способности между процессами
  • Особенности: Гарантирует пропускную способность для каждого процесса
  • Лучше всего для: Интерактивных и десктопных систем, многопользовательских сред

none

  • Принцип работы: Без планировщика, запросы передаются напрямую
  • Особенности: Минимальные накладные расходы
  • Лучше всего для: Быстрых устройств с собственными алгоритмами оптимизации

3. Анализ целесообразности изменения планировщиков

Для vdd (основное хранилище данных):

Проблемы: 100% утилизация, высокие задержки записи, OLAP-нагрузка с преобладанием чтения

Оценка альтернатив:

  1. Оставить mq-deadline:
  2. ✅ Приоритет чтения важен для OLAP
  3. ✅ Deadline механизм предотвращает голодание
  4. ❌ Не решает проблему 100% утилизации
  5. Перейти на kyber:
  6. ✅ Адаптивное управление очередями
  7. ✅ Хорошо для виртуализированных сред
  8. ❌ Разработан для быстрых SSD/NVMe (неизвестен тип накопителя)
  9. ❌ Меньший приоритет чтения перед записью
  10. Перейти на bfq:
  11. ❌ Большие накладные расходы
  12. ❌ Не оптимален для серверных нагрузок
  13. ❌ Может ухудшить производительность при 100% утилизации
  14. Перейти на none:
  15. ❌ Опасен при высоких очередях
  16. ❌ Может привести к полному захвату устройства одним процессом
  17. ❌ Требует тщательного мониторинга

Рекомендация для vdd: Оставить mq-deadline, но рассмотреть тонкую настройку параметров

Для vdc (журнал транзакций):

Текущее состояние: Умеренная нагрузка, только запись, хорошая производительность

Оценка альтернатив:

  1. Оставить mq-deadline:
  2. ✅ Стабильная работа подтверждена данными
  3. ✅ Хорошо справляется с последовательной записью
  4. ✅ Deadline механизм важен для журналов
  5. Перейти на kyber:
  6. ✅ Возможна оптимизация задержек
  7. ❌ Незначительный потенциальный выигрыш

Рекомендация для vdc: Оставить mq-deadline

4. Тонкая настройка mq-deadline для vdd

Если устройство vdd — это HDD (вероятно, учитывая высокие задержки):

# Увеличение времени дедлайна для записи (по умолчанию 5 секунд)

echo 10000 > /sys/block/vdd/queue/iosched/write_expire

# Уменьшение времени дедлайна для чтения (по умолчанию 500 мс)

echo 250 > /sys/block/vdd/queue/iosched/read_expire

# Увеличение размера пакета (может улучшить пропускную способность)

echo 16 > /sys/block/vdd/queue/iosched/fifo_batch

# Увеличение количества запросов в очереди (осторожно!)

echo 256 > /sys/block/vdd/queue/nr_requests

Если устройство vdd — это SSD:

# Уменьшение времени дедлайна для записи

echo 5000 > /sys/block/vdd/queue/iosched/write_expire

# Уменьшение времени дедлайна для чтения

echo 100 > /sys/block/vdd/queue/iosched/read_expire

# Увеличение размера пакета для SSD

echo 32 > /sys/block/vdd/queue/iosched/fifo_batch

# Рассмотреть переход на kyber

echo kyber > /sys/block/vdd/queue/scheduler

5. Мониторинг и тестирование изменений

Прежде чем вносить изменения:

# Сохранить текущие настройки

cat /sys/block/vdd/queue/iosched/* > ~/mq-deadline-backup.txt

После изменений мониторить:

# Глубина очереди

cat /sys/block/vdd/queue/nr_requests

# Статистика планировщика

cat /sys/block/vdd/queue/iosched/*

# Производительность в реальном времени

iostat -x 1

6. Выводы и рекомендации

Основной вывод:

Текущий выбор планировщика (mq-deadline) является оптимальным для текущей нагрузки, учитывая:

  1. Преобладание операций чтения на vdd
  2. Последовательную запись на vdc
  3. Высокую утилизацию устройств

Рекомендации по оптимизации:

Определить тип накопителя vdd:

cat /sys/block/vdd/queue/rotational

Если 1 — HDD, оставлять mq-deadline с тонкой настройкой

Если 0 — SSD, можно протестировать kyber

Настройка параметров mq-deadline для vdd:

# Для HDD

echo 10000 > /sys/block/vdd/queue/iosched/write_expire

echo 250 > /sys/block/vdd/queue/iosched/read_expire

# Проверить результат

iostat -x 1 | grep vdd

A/B тестирование (только в периоды низкой нагрузки):

# Тест kyber

echo kyber > /sys/block/vdd/queue/scheduler

# Мониторить 15-30 минут

# Вернуть обратно при ухудшении

echo mq-deadline > /sys/block/vdd/queue/scheduler

Документирование изменений:

Зафиксировать исходные параметры

Записать все изменения

Сравнить метрики "до" и "после"

Критическое предупреждение:

Основная проблема vdd — 100% утилизация и высокие задержки. Изменение планировщика не решит эту проблему кардинально.

Необходимо:

  1. Увеличить ресурсы (RAM, быстрые диски)
  2. Оптимизировать запросы СУБД
  3. Рассмотреть балансировку нагрузки между несколькими дисками

Планировщик — это инструмент управления очередями, а не увеличения пропускной способности устройства.

Анализ основан на данных мониторинга от 05.01.2026 и текущей конфигурации планировщиков.