Рекомендации по изменению параметров ОС

Эксперимент-5: Настройки кэширования и буферизации.

Эксперимент-7: Оптимизация параметров файловой системы.

Монтирование с опциями noatime,nodiratime

Noatime и nodiratime — параметры монтирования файловых систем в Linux, которые позволяют отключить обновление информации о времени доступа к файлам и каталогам.

Noatime полностью отключает запись времени доступа к файлу. Эта опция подходит, если приложения не зависят от atime. Noatime может быть полезен в разделах с интенсивным чтением, где не важна совместимость с ПО, полагающимся на atime. Например, в каталогах статического контента, кэшах, медиабиблиотеках, снапшотах сборок.

Nodiratime отключает обновление времени доступа только для каталогов. Для остальных файлов время atime будет обновляться всегда. Отдельный nodiratime актуален только при желании тонко выключить обновление atime для каталогов, оставив его для файлов (редкий случай).

Настройка файловой системы /data - изменение параметров mount

1. Проверка текущих опций монтирования

# Текущее состояние

mount | grep/data

2. Определение UUID устройства (рекомендуется использовать UUID вместо пути устройства)

# Получить UUID устройства

blkid /dev/mapper/vg_data-LG_data

3. Резервное копирование текущего fstab

cp /etc/fstab /etc/fstab.backup_$(date +%Y%m%d)

4. Редактирование /etc/fstab

vi /etc/fstab

добавить

# /data

/dev/mapper/vg_data-LG_data /data ext4 defaults,noatime,nodiratime 0 0

5. Перемонтирование файловой системы

mount -o remount /data

6. Проверка применённых опций

# Проверить текущие опции монтирования

mount | grep/data

Важные замечания:

1. noatime vs relatime:

o noatime — полностью отключает обновление atime

o relatime (по умолчанию) — обновляет atime, только если mtime/ctime новее

o nodiratime — отключает atime только для директорий

2. Эффект от изменений:

o Уменьшение нагрузки на диск (меньше операций записи)

o Повышение производительности для workloads с частым чтением

o Некоторые приложения (например, backup-утилиты, использующие atime) могут работать некорректно

Итоговый отчет по анализу производительности подсистемы IO

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

• Период анализа: 06.01.2026 14:42 – 16:31 (около 2 часов)

• Основные устройства хранения:
  vdd (100 ГБ, монтирован в /data):
  Используется под нагрузку чтения и записи
  Наблюдается 100% утилизация (%util = 100)
  Высокие показатели w_await (до 13 мс)
  vdc (50 ГБ, монтирован в /wal):
  Преимущественно запись
  Утилизация 53–63%
  Низкое время отклика на запись (~1 мс)
  Другие диски: vda (система), vdb (лог)

• Тип нагрузки: OLAP-сценарий с преобладанием операций чтения над записью (соотношение ~3.36:1). Нагрузка не ограничена пропускной способностью дисков.

2. Критические проблемы производительности

1. 100% утилизация диска vdd в течение всего периода наблюдения.

2. Высокое время отклика на запись (w_await) на vdd:
   94.55% наблюдений превышают 5 мс
   Максимум до 13 мс

3. Большая длина очереди (aqu_sz) на vdd:
   Всегда > 1, достигает 31
   Указывает на перегруженность диска

4. Высокий cpu_wa (I/O wait):
   100% наблюдений > 10%
   Процессы в состоянии uninterruptible sleep превышают количество ядер CPU в 25–50% случаев

5. Неэффективное использование кэша:
   Высокая корреляция между cache и w/s на vdc (0.587)
   Слабая корреляция буферной памяти с операциями чтения/записи

3. Анализ корреляций и паттернов нагрузки

• Отрицательная корреляция wa и util на vdd (-0.3019) — свидетельствует о том, что высокий wa не всегда связан с загрузкой диска.

• Высокая корреляция операционной скорости с чтением блоков (0.7134) — производительность напрямую зависит от операций чтения с диска.

• Низкая/отрицательная корреляция скорости с IOPS и пропускной способностью — указывает, что узкое место не в подсистеме IO.

• Преобладание операций чтения (соотношение read/write = 3.36) — характерно для аналитических нагрузок.

4. Диагностика узких мест IO

Вывод по диагностике:
Основная проблема — высокое время отклика на запись на диске vdd и перегруженность очереди запросов. При этом общая производительность системы не ограничена пропускной способностью или IOPS, что указывает на иные узкие места: вероятно, недостаток RAM, неэффективные запросы или блокировки на уровне СУБД.

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

1. Оптимизация диска vdd:
   Рассмотреть переход на более быстрые диски (SSD/NVMe)
   Разделить нагрузку: выделить отдельный диск для журналов транзакций

2. Оптимизация памяти:
   Увеличить размер буферного кэша СУБД
   Настроить shared_buffers и effective_cache_size в PostgreSQL

3. Оптимизация запросов:
   Провести анализ медленных запросов
   Добавить/оптимизировать индексы для уменьшения seq scan
   Использовать partitioning для больших таблиц

4. Настройка мониторинга:
   Включить детальный мониторинг процессов в состоянии D (uninterruptible sleep)
   Настроить оповещения при %util > 90% и w_await > 5 мс

5. Балансировка нагрузки:
   Рассмотреть использование реплик для чтения
   Возможно, увеличить количество ядер CPU для параллельной обработки запросов

6. Итоговый вывод по производительности IO

Подсистема IO находится в критическом состоянии по следующим причинам:

• Диск vdd постоянно перегружен (100% утилизация)

• Высокое время отклика на запись (до 13 мс)

• Длинная очередь запросов (до 31)

• Высокий I/O wait процессора (до 47%)

Однако основное узкое место — не в пропускной способности дисков, а в:

1. Неэффективном использовании памяти (слабая кэшируемость данных)

2. Большом количестве операций чтения с диска из-за неоптимальных запросов

3. Высокой загрузке CPU в состоянии ожидания IO

Рекомендуется:
Сначала провести оптимизацию на уровне СУБД и приложения (индексы, запросы, кэширование), а затем рассмотреть апгрейд дисковой подсистемы для диска vdd.

Сравнительные результаты: Эксперимент-5: Настройки кэширования и буферизации и Эксперимент-7: Оптимизация параметров файловой системы.

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

Среднее увеличение операционной скорости в ходе Эсперимента-7 по сравнению с Экпериментом-5 составило 7.47%.

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

IOPS

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

Длина очереди (aqu_sz)

Ожидание по чтению

Ожидание по записи

Сравнительный анализ производительности подсистемы IO: Эксперимент-5(Настройки кэширования и буферизации) и Эксперимент-7(Оптимизация параметров файловой системы).

1. Сравнение критических проблем производительности

• Общая проблема в обоих экспериментах: Производительность не ограничена подсистемой IO.

• Основные узкие места: CPU, блокировки, параметры параллелизма, ожидания СУБД.

• Статус аварийного оповещения: В обоих случаях зафиксирована отрицательная корреляция между операционной скоростью и IOPS/MB/s, что указывает на влияние не-IO факторов на производительность.

2. Сравнительный анализ корреляций и паттернов нагрузки

Вывод:

Оба эксперимента демонстрируют сходный паттерн нагрузки — низкая корреляция с метриками IO, что подтверждает, что производительность определяется не дисковыми операциями, а другими компонентами системы (CPU, блокировки, память).

3. Диагностика метрик IO

3.1. r_await (среднее время чтения, мс)

• Эксперимент-5: стабильно ~2–4 мс.

• Эксперимент-7: стабильно ~2–5 мс.

• Изменение: Незначительный рост в эксперименте-7, но в пределах нормы.

3.2. w_await (среднее время записи, мс)

• Эксперимент-5: 3–12 мс, плавный рост.

• Эксперимент-7: 5–13 мс, более выраженный рост к концу теста.

• Изменение: Увеличение задержек записи в эксперименте-7, что может указывать на влияние оптимизаций ФС на операции записи.

3.3. aqu_sz (средняя длина очереди)

• Эксперимент-5: 8–29.

• Эксперимент-7: 13–31.

• Изменение: Увеличение длины очереди в эксперименте-7, что согласуется с ростом w_await.

3.4. proc_b (количество процессов в состоянии блокировки)

• Эксперимент-5: 5–13.

• Эксперимент-7: 4–13.

• Изменение: Незначительные колебания, без явной тенденции.

3.5. cpu_wa (%) (время ожидания CPU)

• Эксперимент-5: 42–47%.

• Эксперимент-7: 39–47%.

• Изменение: Снижение cpu_wa в эксперименте-7, что может указывать на улучшение использования CPU после оптимизации ФС.

3.6. Корреляция speed – IOPS

Отрицательная в обоих случаях, сильнее в эксперименте-7. Это подтверждает, что рост IOPS не ведёт к росту производительности, проблема в других подсистемах.

3.7. Корреляция speed – пропускная способность

Отрицательная, слабее, чем с IOPS. Пропускная способность диска не является ограничивающим фактором.

3.8. Другие показатели производительности IO

• IOPS: в эксперименте-7 немного выше (до 4346 vs 4293 в эксперименте-5).

• MB/s: стабильно ~39–43 MB/s в обоих экспериментах.

• Utilization: 100% в обоих случаях, что говорит о полной загрузке устройства.

3.9. Вывод по диагностике узких мест IO

• Эксперимент-5: Стабильные показатели IO, узкое место — CPU/блокировки.

• Эксперимент-7: Ухудшение w_await и aqu_sz, но улучшение cpu_wa. Оптимизация ФС привела к увеличению задержек записи, но снизила нагрузку на CPU.

4. Итоговый вывод по сравнению производительности IO в ходе экспериментов

1. Оба эксперимента подтверждают, что узкое место — не в подсистеме IO, а в CPU, блокировках или настройках СУБД.

2. Эксперимент-7 (оптимизация ФС) показал:

3. Увеличение задержек записи (w_await) и длины очереди (aqu_sz).

4. Снижение времени ожидания CPU (cpu_wa).

5. Более сильную отрицательную корреляцию speed-IOPS, что указывает на ещё меньшую зависимость производительности от IO.

6. Эксперимент-5 (настройки кэширования) демонстрирует более стабильные задержки IO, но более высокую нагрузку на CPU.

7. Рекомендация:

8. Продолжить оптимизацию CPU, параллелизма и настройки СУБД.

9. Для экспериментов с ФС рекомендуется дополнительная настройка параметров записи для снижения w_await.

10. Мониторинг блокировок и contention в СУБД.

Заключение:

Оба эксперимента успешно идентифицировали, что производительность упирается не в IO, а в другие компоненты системы. Оптимизация файловой системы (Эксперимент-7) частично улучшила использование CPU, но ухудшила задержки записи. Это указывает на необходимость комплексной настройки системы, учитывающей как параметры ФС, так и настройки СУБД и CPU.

В рамках проекта PG_EXPECTO по всесторонней оптимизации СУБД PostgreSQL был проведён цикл экспериментов по настройке подсистемы ввода-вывода. В ходе «Эксперимента-5» фокус сместился на тонкую настройку механизмов кэширования и буферизации операционной системы. Целью было оценить, как управление памятью для метаданных файловой системы может повлиять на общую производительность дисковой подсистемы в условиях аналитической (OLAP) нагрузки, где чтение данных преобладает над записью. Результаты оказались показательными: даже одна корректировка параметра vm.vfs_cache_pressure принесла ощутимое улучшение.

Рекомендации по изменению параметров ОС

Эксперимент-3: Параметры IO-планировщика

Эксперимент-5: Настройки кэширования и буферизации.

vm.vfs_cache_pressure

Параметр в Linux, который контролирует склонность ядра к освобождению памяти, используемой для кэширования объектов VFS (Virtual File System). Влияет на баланс между кэшем страниц и кэшем метаданных файловой системы.

Текущее значение:

sysctl vm.vfs_cache_pressure

# sysctl vm.vfs_cache_pressure

vm.vfs_cache_pressure = 100

Изменение:

sysctl -w vm.vfs_cache_pressure=50

# sysctl -w vm.vfs_cache_pressure=50

vm.vfs_cache_pressure = 50

# sysctl vm.vfs_cache_pressure

vm.vfs_cache_pressure = 50

Основание:

Уменьшает давление на кэш dentry и inode, что может улучшить кэширование файловых операций.

Ожидаемый эффект:

Улучшение эффективности кэша, снижение нагрузки на дисковые операции чтения.

Итоговый отчет по анализу производительности подсистемы IO

Общая характеристика системы

• Период анализа: 2026-01-06 11:36 – 2026-01-06 13:25 (около 1 часа 50 минут)

• Основные устройства хранения:
  vdd (100 ГБ, LVM /data) – основное устройство данных
  vdc (50 ГБ, LVM /wal) – устройство для журналов
  vdb (30 ГБ, LVM /log) – логи
  vda (70 ГБ) – системный диск

• Тип нагрузки: OLAP-сценарий с преобладанием операций чтения над записью (соотношение ~3.24:1). Нагрузка на оба диска (vdd и vdc) высокая, с признаками очередей и ожиданий.

Критические проблемы производительности

1. Диск vdd перегружен:
   %util = 100% на протяжении всего периода
   w_await > 5 мс в 90.9% наблюдений
   aqu_sz (средняя длина очереди) > 1 в 100% наблюдений
   cpu_wa > 10% в 100% наблюдений

2. Диск vdc также показывает высокую загрузку:
   %util = 51–62% (всё время выше 50%)
   Запись стабильна, но загрузка высокая

3. Высокое соотношение чтения к записи (3.24:1) указывает на аналитическую нагрузку, требующую оптимизации кэширования и стратегий чтения.

Анализ корреляций и паттернов нагрузки

• Для vdd:
  Высокая положительная корреляция buff – r/s (0.899) и buff – wMB/s (0.806) – память неэффективно снижает нагрузку на диск.
  Отрицательная корреляция speed – IOPS (-0.593) – проблема не в IOPS, а в других подсистемах (CPU, блокировки).

• Для vdc:
  Слабая корреляция speed – IOPS (0.252) – IOPS не является узким местом.
  Отрицательная корреляция speed – MB/s (-0.115) – пропускная способность не ограничивает.

Вывод: Проблема производительности связана не с пропускной способностью или IOPS, а с задержками, очередями и, возможно, с настройками СУБД или CPU.

Диагностика узких мест IO

Вывод по диагностике узких мест IO:
Основное узкое место – высокие задержки записи и большая очередь на диске vdd, что приводит к ожиданию со стороны CPU (wa высокий). Проблема усугубляется неэффективным использованием памяти для буферизации.

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

1. Оптимизация диска vdd:
   Рассмотреть переход на более быстрые диски (SSD/NVMe).
   Настроить параметры IO-планировщика (например, deadline или noop для SSD).
   Увеличить размер очереди (nr_requests).

2. Оптимизация памяти и кэширования:
   Увеличить shared_buffers (если это СУБД, например PostgreSQL).
   Настроить vm.dirty_ratio и vm.dirty_background_ratio для более эффективной записи.

3. Оптимизация запросов и схемы данных:
   Использовать индексы, секционирование, материализованные представления.
   Пересмотреть запросы с большим количеством чтений.

4. Мониторинг и дальнейший анализ:
   Следить за iowait, await, aqu_sz в реальном времени.
   Анализировать логи СУБД на предмет медленных запросов.

5. Для vdc:
   Мониторить утилизацию, при росте нагрузки – рассмотреть выделение более производительного диска.

Итоговый вывод по производительности IO

Текущее состояние: Критическое.
Диск vdd является основным узким местом – постоянная 100% загрузка, высокие задержки записи, большая очередь запросов. Это приводит к простою CPU в ожидании IO и снижению общей производительности системы.

Перспективы:
При оптимизации диска vdd, настроек памяти и запросов можно ожидать значительного улучшения производительности. Диск vdc работает в допустимом режиме, но требует наблюдения.

Рекомендуемые первоочередные действия:

1. Апгрейд vdd на SSD.

2. Настройка параметров кэширования и записи в ОС и СУБД.

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

*Отчет подготовлен на основе автоматизированного анализа метрик iostat/vmstat за период 06.01.2026 11:36–13:25.*

Сравнительные результаты: Эксперимент-3(Параметры IO-планировщика) и Эксперимент-5: Настройки кэширования и буферизации

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

Среднее увеличение операционной скорости в ходе Эсперимента-5 по сравнению с Экпериментом-3 составило 30.82%.

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

IOPS

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

Длина очереди (aqu_sz)

Ожидание по чтению

Ожидание по записи

Сравнительный анализ производительности подсистемы IO: Эксперимент-3(Параметры IO-планировщика) и Эксперимент-5: Настройки кэширования и буферизации

1. Сравнение критических проблем производительности

Вывод: В обоих экспериментах IO-подсистема не является узким местом. Проблема производительности связана с другими компонентами системы (CPU, блокировки, память).

2. Сравнительный анализ корреляций и паттернов нагрузки

Вывод: Оба эксперимента демонстрируют схожий паттерн — отсутствие значимой корреляции между производительностью и метриками IO, что подтверждает гипотезу о том, что ограничение находится вне IO-подсистемы.

3. Диагностика метрик IO

3.1 Задержки операций (латентности)

Наблюдение: Латентности операций чтения и записи находятся в приемлемых пределах в обоих экспериментах.

3.2 Очереди и блокировки

Наблюдение: Наблюдается рост длины очереди и количества заблокированных процессов, но значения не критичны.

3.3 Загрузка CPU

Наблюдение: Высокий процент времени ожидания IO процессором в обоих экспериментах, что может указывать на неоптимальное взаимодействие CPU и IO.

3.4 Дополнительные показатели производительности IO

Наблюдение: Показатели IOPS и пропускной способности сопоставимы в обоих экспериментах. Время операций с блоками демонстрирует схожую динамику роста.

3.5 Вывод по диагностике узких мест IO

IO-подсистема не является ограничивающим фактором в обоих экспериментах по следующим причинам:

1. Низкие латентности операций чтения/записи

2. Отсутствие значимых корреляций между производительностью и метриками IO

3. Умеренные значения длины очереди и заблокированных процессов

4. Схожие показатели IOPS и пропускной способности в обоих экспериментах

4. Итоговый вывод по сравнению производительности IO в ходе экспериментов

1. Консистентность результатов: Оба эксперимента демонстрируют одинаковый основной вывод — IO-подсистема не является узким местом в системе.

2. Эффективность оптимизаций: Эксперимент 5 (с настройками кэширования и буферизации) показал:
   Незначительное улучшение latencies (особенно r_await)
   Слегка сниженные значения cpu_wa
   Сопоставимые основные показатели IOPS и пропускной способности

3. Рекомендации:
   Сфокусироваться на оптимизации CPU, устранении блокировок и настройке параллелизма
   Рассмотреть оптимизацию работы с памятью
   Провести детальный анализ времени выполнения запросов СУБД
   Настройки кэширования из эксперимента 5 можно считать успешными, но недостаточными для решения основной проблемы производительности

4. Общий вывод: Проблема производительности в обоих случаях связана с факторами вне IO-подсистемы. Оптимизации кэширования (эксперимент 5) дали незначительные улучшения, но не решили основную проблему, что подтверждает необходимость дальнейшего исследования CPU, блокировок и параметров параллелизма.

В мире высоконагруженных баз данных каждая миллисекунда ожидания ввода-вывода может стать узким местом всей системы. В поисках решения администраторы часто обращаются к настройке глубины очереди запросов к диску (nr_requests), надеясь одним параметром решить проблему высокой утилизации хранилища. Данный разбор на реальных метриках показывает, что вслепую увеличивать очередь не только бесполезно, но иногда и вредно. Когда диск постоянно работает на 100%, ключ к оптимизации лежит не в очереди, а в грамотном перераспределении нагрузки, стратегическом кэшировании и настройке планировщика операций ввода-вывода.

Запрос нейросети

Проанализируй показатели производительности IO и текущие значения для параметра nr_requests :"# cat /sys/block/vdd/queue/nr_requests

256". Подготовь рекомендации о целесообразности изменения параметра nr_requests для оптимизации подсистемы IO.

На основе анализа производительности IO для диска vdd, текущего значения nr_requests = 256 и контекста нагрузки, можно дать следующие рекомендации:

Текущее состояние (диск vdd):

1. Высокая загрузка диска:
   %util = 100% постоянно
   Средняя длина очереди (aqu_sz) от 11 до 29
   Большое количество процессов в состоянии uninterruptible sleep (6-14 при 8 CPU)

2. Характер нагрузки:
   Преобладание операций чтения над записью (соотношение ~3:1)
   OLAP-подобный сценарий с интенсивным чтением
   Высокая корреляция между объемом кэша и объемом чтения с диска

3. Проблемы:
   Чрезмерное ожидание IO процессором (wa = 45-51%)
   Глубина очереди постоянно > 1 (100% наблюдений)
   Признаки недостаточной эффективности кэширования

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

Текущее значение 256:

• Достаточно высокое для большинства рабочих нагрузок

• НЕ является основным ограничивающим фактором при текущей нагрузке

• Увеличение не решит проблему 100% утилизации

Рекомендуемые действия:

НЕ увеличивать nr_requests (256 → более высокие значения):

Текущая очередь и так переполнена (aqu_sz до 29)

Увеличение nr_requests не снизит %util = 100%

Может привести к:

• Увеличению латентности отдельных запросов

• Росту потребления памяти ядром

• Эффекту "застревания" старых запросов

Оптимизировать параметры планировщика (scheduler):

# Для OLAP-нагрузки с преобладанием чтения

echo deadline > /sys/block/vdd/queue/scheduler
# Настройки для deadline (опционально)
echo 256 > /sys/block/vdd/queue/iosched/read_expire
echo 5000 > /sys/block/vdd/queue/iosched/write_expire
echo 8 > /sys/block/vdd/queue/iosched/fifo_batch

Увеличить readahead для последовательных чтений:

# Текущее значение обычно 128 или 256
cat /sys/block/vdd/queue/read_ahead_kb
# Увеличить для OLAP
echo 4096 > /sys/block/vdd/queue/read_ahead_kb

Приоритетные оптимизации:
Увеличить кэширование (если возможно добавить RAM)
Оптимизировать запросы БД (индексы, уменьшение seq scan)
Рассмотреть разделение нагрузки на несколько дисков
Проверить настройки ФС (noatime, nodiratime)

Экспериментальная проверка (если решили изменить nr_requests):

#Временно уменьшить для теста
echo 128 > /sys/block/vdd/queue/nr_requests

# Мониторинг эффекта
iostat -x 1
cat /proc/interrupts | grep vdd

Вывод:

Параметр nr_requests = 256 не является узким местом.

Проблема :

1. Слишком высокой нагрузке на диск (OLAP + вероятно недостаток кэша)

2. Возможно, недостаточной производительности самого диска для текущей нагрузки

Рекомендация:

Сфокусироваться на:

1. Увеличении оперативной памяти для кэширования

2. Оптимизации запросов к базе данных

3. Рассмотрении более производительного хранилища (SSD/NVMe вместо HDD)

4. Настройке параметров планировщика и readahead

Изменение nr_requests даст минимальный эффект и может ухудшить ситуацию при текущей 100% утилизации диска.

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

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

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:
   ✅ Приоритет чтения важен для OLAP
   ✅ Deadline механизм предотвращает голодание
   ❌ Не решает проблему 100% утилизации

2. Перейти на kyber:
   ✅ Адаптивное управление очередями
   ✅ Хорошо для виртуализированных сред
   ❌ Разработан для быстрых SSD/NVMe (неизвестен тип накопителя)
   ❌ Меньший приоритет чтения перед записью

3. Перейти на bfq:
   ❌ Большие накладные расходы
   ❌ Не оптимален для серверных нагрузок
   ❌ Может ухудшить производительность при 100% утилизации

4. Перейти на none:
   ❌ Опасен при высоких очередях
   ❌ Может привести к полному захвату устройства одним процессом
   ❌ Требует тщательного мониторинга

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

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

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

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

1. Оставить mq-deadline:
   ✅ Стабильная работа подтверждена данными
   ✅ Хорошо справляется с последовательной записью
   ✅ Deadline механизм важен для журналов

2. Перейти на kyber:
   ✅ Возможна оптимизация задержек
   ❌ Незначительный потенциальный выигрыш

Рекомендация для 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 и текущей конфигурации планировщиков.

На основе детального сравнительного анализа двух экспериментов по оптимизации подсистемы ввода-вывода (IO) для PostgreSQL, был получен ключевой и несколько неожиданный вывод. Эксперименты по настройке параметров отложенной записи (vm.dirty_ratio) и выбору IO-планировщика (deadline) показали, что само по себе тонкое регулирование дисковых операций не является решением фундаментальной проблемы производительности в данной системе. Несмотря на некоторые изменения в метриках (рост IOPS, увеличение задержек), основное узкое место сместилось в сторону процессорных ресурсов (CPU), блокировок и настроек параллелизма внутри СУБД. Этот отчёт наглядно иллюстрирует важность комплексной диагностики: прежде чем оптимизировать диск, стоит убедиться, что проблема действительно в нём.

Рекомендации по изменению параметров ОС

Эксперимент-2 (dirty_ratio , 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) — основное хранилище данных
  vdc (50 ГБ, LVM /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. Рекомендации по оптимизации

1. Для vdd (данные):
   Увеличить объём RAM для кэширования данных
   Оптимизировать запросы СУБД: добавить индексы, избегать полных сканирований
   Настроить параметры PostgreSQL:
   Увеличить work_mem
   Настроить shared_buffers
   Проверить effective_cache_size
   Рассмотреть использование более быстрых дисков (SSD/NVMe)
   Балансировка нагрузки: распределить данные по нескольким дискам

2. Для vdc (журнал):
   Текущая конфигурация адекватна, рекомендуется мониторинг

3. Общие рекомендации:
   Мониторинг процессов в состоянии D
   Анализ журналов СУБД на предмет медленных запросов
   Проверка настроек IO-планировщика

6. Итоговый вывод по производительности IO

Система испытывает серьёзные проблемы с производительностью IO на основном диске данных (vdd).
Устройство постоянно перегружено, наблюдаются высокие задержки записи и длинные очереди запросов. Это напрямую влияет на производительность приложений, о чём свидетельствует высокий cpu_wa и сильная зависимость скорости операций от дискового чтения.

Рекомендуется срочная оптимизация: увеличение RAM, настройка СУБД и рассмотрение апгрейда дисковой подсистемы. Устройство vdc проблем не вызывает и может оставаться в текущей конфигурации.

Отчет подготовлен на основе данных мониторинга за период 05.01.2026 15:02–16:51

Сравнительные результаты: Эксперимент-2 (vm.dirty_ratio/vm.dirty_background_ratio) и Эксперимент-3(Параметры IO-планировщика)

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

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

IOPS

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

Длина очереди (aqu_sz)

Ожидание по чтению

Ожидание по записи

Сравнительный анализ производительности подсистемы IO: Эксперимент-2 (vm.dirty_ratio/vm.dirty_background_ratio) и Эксперимент-3(Параметры IO-планировщика)

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 в ходе экспериментов

1. IO не является ограничивающим фактором ни в одном из экспериментов.

2. Изменение параметров IO (dirty_ratio, планировщик) не привело к значимому улучшению производительности системы.

3. Нагрузка остаётся CPU-интенсивной с признаками contention (блокировки, ожидания).

4. Эксперимент 3 показал незначительный рост IOPS и MB/s, но задержки (await) и очередь (aqu_sz) выросли, что может указывать на повышенную конкуренцию за ресурсы.

5. Рекомендации:
   Сфокусироваться на оптимизации CPU (профилирование, настройка параллелизма).
   Исследовать блокировки и ожидания в СУБД.
   Рассмотреть возможность увеличения вычислительных ресурсов или оптимизации запросов.

Заключение: Оба эксперимента подтверждают, что проблема производительности лежит вне подсистемы IO. Требуется углублённый анализ CPU, блокировок и настроек параллелизма для дальнейшей оптимизации.

Итог эксперимента-3 по сравнению с экспериментом-2

Изменение параметров IO-планировщика привело к снижению производительности СУБД при низкой нагрузке и повышению производительности СУБД при высокой нагрузке, при практически неизменном значении ожиданий СУБД.

Эксперимент 3 показал незначительный рост IOPS и MB/s, но задержки (await) и очередь (aqu_sz) выросли, что может указывать на повышенную конкуренцию за ресурсы.

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

Базовые показатели 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. Рекомендации по оптимизации

Увеличить кэширование:

• Добавить оперативной памяти для увеличения buff/cache

• Настроить параметры СУБД (shared_buffers, work_mem для PostgreSQL)

Оптимизировать запросы:

• Анализ и перестройка индексов

• Использование секционирования таблиц

• Уменьшение объёма читаемых данных (поля, фильтрация)

Настройка дисковой подсистемы:

• Рассмотреть использование более быстрых дисков (SSD/NVMe) для vdd

• Проверить и настроить параметры файловой системы и монтирования (noatime, nodiratime)

Оптимизация процессов:

• Выявление и оптимизация процессов в состоянии D (возможно, тяжёлые запросы или фоновые задачи)

• Настройка лимитов и приоритетов IO (ionice, cgroups)

6. Итоговый вывод по производительности IO

Подсистема IO находится под критической нагрузкой, особенно диск vdd.

Основная проблема — не диски, а CPU, который простаивает в ожидании IO, что указывает на неэффективное использование памяти, высокую нагрузку на чтение и возможные блокировки на уровне приложения/СУБД.

Сравнительные результаты Эксперимент-1(Базовые показатели) и Эксперимент-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)

Ожидание по чтению

Ожидание по записи

Сравнительный анализ производительности подсистемы IO: Эксперимент-1 (BASELINE) vs Эксперимент-2 (vm.dirty_ratio/vm.dirty_background_ratio)

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 из-за изменения паттерна записи.

Рекомендации по дальнейшей оптимизации:

• Сфокусироваться на диагностике CPU: анализ профилирования, поиск тяжёлых запросов, оптимизация индексов.

• Исследовать блокировки и ожидания в СУБД.

• Настроить параметры параллелизма и пулы соединений.

• Вернуть настройки dirty в исходное состояние, если они не дали положительного эффекта.

Заключение:

Эксперимент-2 подтвердил выводы Эксперимента-1: проблема производительности лежит вне подсистемы IO.

Изменения в настройках отложенной записи не привели к улучшениям и даже усилили признаки CPU-ограничения.

Далее следует сосредоточиться на оптимизации CPU и работы СУБД.

Итог эксперимента-2

Изменение настроек vm.dirty_ratio/vm.dirty_background_ratio в целом оказало положительное влияние на производительность СУБД , однако существенного влияния на производительности дисковой подсистемы IO не было достигнуто.