IO delay в Proxmox — это процент времени, в течение которого процессор простаивает в ожидании завершения операций ввода-вывода, и увидеть его можно прямо на вкладке Summary узла в веб-интерфейсе или командой top в консоли (строка wa). Если значение стабильно держится выше 10–20% под нагрузкой, виртуальные машины начинают «подтормаживать»: запись на диск затягивается, приложения отвечают с задержкой, а бэкапы выполняются дольше обычного.
Единой «официальной нормы» для IO delay не существует — допустимый уровень зависит от типа нагрузки и железа. Однако на практике администраторы ориентируются на простые ориентиры: до 5% — комфортная работа, 5–15% — допустимо при пиковых нагрузках, выше 20–30% в течение продолжительного времени — сигнал к диагностике дисковой подсистемы. Дальше разберём, от чего зависят эти цифры и что проверить в первую очередь.
Что такое IO delay и как он измеряется
Показатель IO delay (или IO wait) отражает долю времени, когда CPU готов работать, но вынужден ждать ответа от дисковой подсистемы. Важно понимать: сам по себе IO delay не означает поломку — он лишь показывает, что диски не успевают обрабатывать поток запросов от гипервизора и виртуальных машин.
Посмотреть текущее значение можно несколькими способами. В веб-интерфейсе Proxmox VE откройте узел и перейдите на вкладку Summary — график IO delay строится там по умолчанию. В консоли используются стандартные утилиты:
top
iostat -xz 2
iostat -xz /dev/sda 5
В выводе top смотрите на параметр wa в строке CPU, а iostat покажет детализацию по каждому диску: await (среднее время ответа в миллисекундах), %util (загруженность устройства) и очередь запросов. Если await на конкретном диске регулярно исчисляется десятками или сотнями миллисекунд — именно это устройство является узким местом.
IO delay — это не ошибка, а симптом перегрузки дисковой подсистемы. Диагностику нужно начинать с поиска конкретного диска или ВМ, создающих очередь запросов.
Какой IO delay считается нормой
Жёсткого стандарта нет, но на практике приняты ориентировочные границы. Кратковременные всплески до 30–50% во время бэкапов, миграций или обновлений — нормальное явление, особенно на SATA-дисках. Тревожным считается устойчиво высокий фон без явной причины.
| Уровень IO delay | Оценка состояния | Рекомендуемое действие |
|---|---|---|
| 0–5% | Норма для большинства задач | Ничего не требуется |
| 5–15% | Допустимо при пиковых нагрузках | Наблюдать, проверить расписание бэкапов |
| 15–30% | Повышенная задержка | Найти источник нагрузки, проверить диски |
| 30–50% | Заметная деградация производительности | Диагностика: SMART, кэш, тип хранилища |
| Более 50% длительное время | Критично, ВМ практически «висят» | Срочный разбор: отказ диска, переполнение ZFS, проблемы с сетью для сетевых хранилищ |
Эти пороги — ориентир, а не догма. На сервере с NVMe-массивом даже 10% уже повод присмотреться, а для узла на обычных HDD с интенсивной записью 15% может быть привычным рабочим режимом.
Основные причины высокого IO delay
Прежде чем что-то менять, определите источник. Чаще всего виновником оказывается одна из типовых причин:
- 🔧 Медленные или деградирующие диски — изношенные HDD, дешёвые SSD без DRAM-кэша, накопители с растущим числом переназначенных секторов.
- 💾 Отсутствие или отключение кэша записи — на RAID-контроллерах без BBU и на потребительских SSD запись идёт напрямую, что резко повышает задержки.
- 🗄️ Особенности ZFS — заполнение пула более чем на 80–90%, нехватка RAM для ARC, отсутствие SLOG-устройства при синхронных записях.
- 🌐 Сетевые хранилища — NFS, Ceph или iSCSI при перегруженной сети добавляют свои задержки поверх дисковых.
- 🚜 «Шумные соседи» — одна ресурсоёмкая ВМ (база данных, антивирусное сканирование, торренты) забивает очередь ввода-вывода для всех остальных.
Отдельного внимания заслуживают бэкапы и репликации. Если график IO delay показывает регулярные «пики» в одно и то же время — почти наверняка это расписание задач vzdump или репликации ZFS. Такие пики сами по себе не проблема, если не мешают работе сервисов.
⚠️ Внимание: резкий рост IO delay, сопровождающийся ошибками в dmesg (например, I/O error, ata exceptions, таймауты команд), обычно указывает на аппаратную проблему диска или кабеля. В этом случае первым делом проверьте SMART и сделайте резервные копии важных данных — до любых экспериментов с настройками.
Диагностика: пошаговая проверка
Начните с локализации проблемы — какой диск и какая ВМ создают нагрузку. Утилита iotop покажет процессы с максимальной дисковой активностью, а iostat -xz 2 — загруженность каждого устройства в реальном времени.
☑️ Диагностика высокого IO delay
Проверку состояния дисков выполняют через smartctl:
smartctl -a /dev/sda | egrep -i "realloc|pending|wear|percent"Обратите внимание на Reallocated Sector Count, Current Pending Sectors и показатели износа SSD. Любые растущие значения — повод планировать замену накопителя. Для ZFS дополнительно смотрите zpool status: ошибки checksum, read или write на конкретном устройстве указывают на проблемный диск или контроллер.
Если пики IO delay совпадают по времени с бэкапами, попробуйте ограничить скорость резервного копирования параметром bwlimit в настройках задачи vzdump — это сгладит нагрузку без изменения расписания.
Способы снижения IO delay
После диагностики можно переходить к оптимизации. Порядок действий зависит от найденной причины, но есть набор мер, которые помогают в большинстве сценариев.
- ⚡ Включите кэш записи на дисках ВМ — в настройках виртуального диска (Hardware → Hard Disk → Edit) параметр
Cache: Write backзаметно снижает задержки записи, но требует защиты от внезапного отключения питания. - 🧩 Используйте VirtIO Block или VirtIO SCSI вместо эмуляции IDE/SATA — паравиртуализированные драйверы дают существенно меньшие накладные расходы.
- 📦 Разнесите нагрузку — перенесите «тяжёлые» ВМ на отдельный диск или пул, отделите хранилище бэкапов от рабочих данных.
- 🛡️ Для ZFS добавьте SLOG на быстром SSD с защитой от потери питания, если нагрузка состоит из синхронных записей (базы данных, NFS).
- 🗜️ Проверьте discard/TRIM — включённый
discard=onи thin provisioning помогают SSD поддерживать скорость записи со временем.
При работе с Ceph или другими сетевыми хранилищами отдельно проверьте сетевую инфраструктуру: задержки на уровне сети напрямую транслируются в IO delay. Джамбо-фреймы, выделенная сеть для кластерного трафика и отсутствие перегруженных коммутаторов — базовые условия нормальной работы.
⚠️ Внимание: режим кэшаWrite backускоряет запись, но при внезапном отключении питания повышает риск повреждения файловых систем внутри ВМ. Используйте его только при наличии ИБП с корректно настроенным завершением работы узла, либо оставьтеDefault (No cache)илиWrite throughдля критичных данных.
Почему ZFS иногда показывает высокий IO delay даже на быстрых дисках
ZFS выполняет copy-on-write и контрольные суммы для каждого блока, что увеличивает объём операций. При заполнении пула выше 80% резко растёт фрагментация свободного пространства, и запись замедляется. Синхронные записи (sync writes) без SLOG-устройства идут напрямую в ZIL на основных дисках пула. Также ARC по умолчанию может занимать значительную часть RAM — при нехватке памяти кэш сжимается, и чтение чаще уходит на диски. Решения: держать заполнение пула ниже 80%, выделить отдельный SLOG, при необходимости ограничить ARC через параметр zfs_arc_max.
Мониторинг: как отслеживать IO delay постоянно
Разовая проверка показывает моментальный снимок, но для понимания динамики нужен постоянный сбор метрик. Встроенные графики Proxmox хранят историю, однако для серьёзного мониторинга имеет смысл настроить внешнюю систему — например, связку Prometheus + node_exporter + Grafana или Zabbix, которые собирают iostat-метрики с каждого узла.
Настройте оповещения на два условия: превышение среднего IO delay за интервал (например, выше 20% в течение 15 минут) и появление ошибок в SMART или dmesg. Первое сигнализирует о перегрузке, второе — о возможном отказе оборудования, и реагировать на них нужно по-разному.
Устойчивый IO delay выше 20–30% — это всегда следствие конкретной причины: медленный диск, отсутствие кэша, переполненный пул или «шумная» ВМ. Лечится не «снижением процента», а устранением первопричины.
Частые вопросы
IO delay 100% — что это значит?
Значение около 100% означает, что процессор почти всё время ждёт дисковой подсистемы. Типичные причины: умирающий диск, переполненное хранилище, зависшая сетевая шара (NFS/Ceph) или массовые ошибки ввода-вывода. Проверьте dmesg, zpool status и SMART — обычно источник виден сразу.
Влияет ли высокий IO delay на виртуальные машины?
Да, напрямую. ВМ начинают медленно отвечать, растёт время загрузки приложений, базы данных могут выдавать таймауты, а гостевые системы — свои внутренние ошибки диска. При длительной перегрузке возможны повреждения данных внутри гостей из-за прерванных операций записи.
Какой режим кэша диска ВМ выбрать в Proxmox?
Для большинства случаев подходит Default (No cache) — безопасный и предсказуемый вариант. Write back даёт максимальную скорость записи, но требует ИБП. Write through — компромисс с гарантированной записью, но медленнее. Direct sync обходит кэш полностью и используется редко.
Нормально ли, что IO delay подскакивает во время бэкапа?
Да, это ожидаемо: vzdump читает большие объёмы данных с дисков. Если пики мешают рабочим сервисам, ограничьте скорость бэкапа параметром bwlimit, перенесите задачи на ночное время или используйте отдельное хранилище для резервных копий.
Поможет ли переход с HDD на SSD снизить IO delay?
В подавляющем большинстве случаев — да, причём радикально: задержки SSD на порядки ниже, чем у механических дисков. Но если причина в другом (переполненный ZFS-пул, сетевые проблемы с Ceph, ошибки контроллера), замена дисков эффекта не даст. Сначала диагностика, потом апгрейд.