Короткий ответ

Высокий %wa на pve1 — очередь диска/NFS/iSCSI, не «мало гигагерц». Найдите, кто генерирует IO: конкретный kvm (VM 101), vzdump/proxmox-backup-client, scrub/resilver, thin ENOSPC. Снимайте iostat, ps STAT=D, pvesm status. Не kill -9 qemu и не отключайте backup навсегда без окна.

Сначала докажите backend: локальный local-lvm/rpool vs NFS vs iSCSI — разные журналы.

Симптомы и как отличить

Типичная картина:

  • top: %wa высокий, %us низкий;
  • консоль GUI и SSH «тупят»;
  • гости живы, но disk latency секунды;
  • пик в час vzdump.

Отличия:

Что видноНе хостовый iowaitКуда смотреть
Одна VM медленная, хост %wa 0внутри гостяVM медленно
%st steal внутри VMCPU overcommitта же статья
Thin 100%пулLVM-thin
ZFS DEGRADEDдискZFS degraded
Backup error в логезадачаvzdump, PBS

Возможные причины

  1. vzdump snapshot всех VM на один local/NFS ночью.
  2. Одна VM: SQL dump, Windows Update, антивирус full scan.
  3. ZFS scrub/resilver, fstrim сразу на всех гостях.
  4. Thin почти полный: очередь IO.
  5. NFS/iSCSI latency, flapping path.
  6. qcow2 с длинной цепочкой снимков.

Диагностика

pveversion
uptime
iostat -x 1 5
pvesm status
lvs -a
zpool status rpool

Колонки await, %util, svctm (если есть). Утилизация 100% на sda/zd0/dm- — этот device.

Кто в D-state:

ps -eo pid,stat,wchan,cmd | awk '$2 ~ /D/'
qm list

Сопоставьте cmdline kvm с VMID. Задачи backup:

ps aux | grep -E 'vzdump|proxmox-backup' | grep -v grep
cat /etc/pve/jobs.cfg

Сеть storage:

dmesg | grep -iE 'nfs|iscsi|I/O error' | tail

Решение

Сценарий A. Виноват vzdump/PBS

Снизьте параллелизм: одна VM, bandwidth limit в job, не пик работы. Отмените текущую задачу штатно в GUI, не SIGKILL qemu. Перенесите окно. Для PBS см. отдельную статью про datastore/квоту, если job ретраит из-за ошибки.

Сценарий B. Одна VM 101

Внутри гостя найдите процесс. На хосте можно ionice не как постоянный костыль. Если гость в D-state из-за своего диска — storage. Если антивирус — политика в госте.

Сценарий C. Thin/ZFS здоровье

Освободите/расширьте thin, дождитесь resilver без дополнительного scrub. Не запускайте zpool scrub параллельно с полным backup.

Сценарий D. NFS/iSCSI

Чините сессию и канал. Временно остановите backup на эту шару. Не переключайтесь на soft NFS.

Сценарий E. Нужно быстро отдать интерактив

Мигрируйте критичную VM на другой узел/storage, если миграция возможна. Это обход, не ремонт диска pve1.

Привязка device из iostat к VM и к задаче backup

iostat даёт sda/zd0/dm-12, не VMID. Переведите в том:

lsblk -o NAME,MAJ:MIN,SIZE,TYPE,MOUNTPOINT
pvesm status
lvs -o lv_name,lv_kernel_major,lv_kernel_minor,pool_lv
zfs get volsize,written rpool/data/vm-101-disk-0 2>/dev/null
ps -eo pid,pcpu,cmd --sort=-pcpu | grep -E 'kvm|vzdump|z_rd|txg' | head

Для ZFS смотрите z_wr_iss/txg в ps и zpool iostat rpool 1. Для NFS — nfsstat -c и rpcinfo. Высокий %util на root-диске узла при backup на local значит, вы пишете vzdump туда же, где ISO и логи: это самострел.

Не запускайте fio на боевом vm-101-disk-0. Тест только на выделенном томе. iostat во время fio на том же пуле всё равно накажет соседей.

Если пик совпадает с fstrim.timer гостей — разнесите таймеры. Если с zfs-scrub systemd — перенесите scrub на выходные, не на окно 1С.

Как проверить, что проблема устранена

iostat -x 1 5
qm status 101
pvesm status

%wa на хосте в норме для вашей базы (не десятки процентов в простое). await не секунды. Гостевые приложения отвечают. Повторный backup в окно с лимитом не кладёт GUI. Журнал без новых nfs: server not responding / thin ENOSPC.

Окно наблюдения, а не один top

Снимите iostat -x 1 30 и qm list в одном интервале, не один кадр top. Пик vzdump длится минуты; вы обязаны увидеть, совпадает ли %util с PID vzdump и VMID в cmdline kvm. Если %util 100% на устройстве без qemu — ищите scrub, RAID rebuild, fstrim, updatedb. Запишите uptime и pveversion в тот же лог: иначе через неделю не понять, на каком ядре это было.

Не «оптимизируйте» elevator/scheduler на PVE 8 без измерения: mq-deadline/none на NVMe уже не те байки из статей про Ubuntu 14. Сначала виновник, потом тюнинг очереди.

Если не помогло

  • %util 100% на SSD с низкой w/s: мелкие sync-записи, cache, не «медленный диск» в бытовом смысле — смотрите fsync гостей.
  • ARC ZFS thrash: мало RAM под ARC при куче VM.
  • Ceph (если есть) — смотрите OSD, не iostat локального sda.
  • После отмены backup wait остался: гость или scrub.
  • GUI тормозит при низком wait: pveproxy или CPU steal на самом хосте не при чём — смотрите pvedaemon.

Профилактика

  • Расписание backup не «все VM в 00:00».
  • Алерт %wa и latency storage.
  • Не хранить qcow+снимки на одном медленном NFS вместе с vzdump.
  • Ограничить bwlimit vzdump.
  • Разнести OS rpool и data, если IO смешанный.

FAQ

Почему iowait высокий, а dd на хосте быстрый?

dd последовательный. Гости бьют random 4K. Тест должен быть похож на нагрузку (fio с понятными параметрами на тестовом томе).

Можно ли echo 3 > drop_caches?

Не лечение iowait. Сбросит кэш и может ухудшить.

ionice -c3 на kvm 101 — идея?

Как временный приоритет фоновой VM — иногда. Как маскировка мёртвого RAID — нет.

Хост 32 ядра, wa 12% — плохо?

Смотрите latency гостей и %util диска. Процент wait на многоядерности не линейно «12% = диск на 12%».

Нужно ли выключать swap на PVE?

Swap под нагрузкой памяти добавляет IO. Не отключайте вслепую как фикс wait; сначала найдите, кто пишет в диск.