Proxmox Backup Server: высокий I/O delay в ZFS

Почему Proxmox Backup Server тормозил при создании бэкапов: диагностика ZFS, переход с IDE на AHCI и поиск медленного SSD​

В этой статье я разберу реальный случай с бюджетным хранилищем бэкапов на Proxmox Backup Server, когда во время создания резервных копий сервер практически упирался в дисковую подсистему.

Симптомы изначально были довольно неприятными: при запуске backup с Proxmox VE на PBS показатель I/O delay мог приближаться к 100%, процесс резервного копирования сильно замедлялся, а сама система начинала реагировать заметно хуже.

При этом загрузка процессора на стороне PVE была небольшой, сеть тоже не выглядела узким местом. Всё указывало именно на хранилище PBS.

В итоге выяснилось, что проблема состояла сразу из нескольких частей:

• SATA-контроллер материнской платы работал в режиме IDE вместо AHCI;
• после переключения AHCI изменились имена Linux-устройств, из-за чего ZFS-пул импортировался DEGRADED;
• один из SSD — SPCC Solid State Disk — оказался значительно медленнее остальных накопителей;
• TRIM улучшил ситуацию, но не устранил проблему SPCC полностью;
• перестановка SSD между SATA-портами окончательно подтвердила, что проблема следует именно за накопителем, а не за портом или кабелем.

Ниже покажу весь путь диагностики.

Исходная конфигурация PBS​

Proxmox Backup Server использовал ZFS-пул home, состоящий из двух mirror vdev:


То есть это не RAID10 в классическом аппаратном понимании, а striped mirrors в ZFS: два зеркала, объединённых в один пул.

Datastore Proxmox Backup Server:


Сам ZFS-пул был заполнен примерно на 60–65%.

Системный диск PBS — отдельный SSD Smartbuy 240 GB.

Первый симптом: почти 100% I/O delay​

Во время резервного копирования в интерфейсе PBS я видел очень высокий I/O delay — временами около 99%.

Сначала нужно было понять, кто именно тормозит: процессор, ZFS в целом или один из физических накопителей.

Для этого я использовал:


и параллельно:


iostat показывает задержки непосредственно на уровне Linux block devices, а zpool iostat позволяет посмотреть распределение операций между vdev и отдельными устройствами ZFS.

Первоначальные показатели были очень плохими.

На некоторых SSD задержка записи w_await доходила до сотен миллисекунд:


При этом реальная скорость записи могла составлять всего несколько мегабайт в секунду.

Для SSD это явно ненормальная ситуация.

Проверяю режим SATA-контроллера​

Следующим шагом я посмотрел, какой драйвер и режим использует SATA-контроллер:


И здесь обнаружилась очень важная деталь.

Контроллер Intel ICH8 работал в режиме IDE:


То есть современные SSD фактически обслуживались через старый IDE/PATA-совместимый режим.

Особенно интересно было то, что два наиболее медленных на тот момент диска находились на одном IDE-канале.

Это стало очень серьёзным подозрением.

Переключаю BIOS с IDE на AHCI​

В BIOS я переключил SATA Controller Mode:


После загрузки Linux контроллер стал выглядеть уже нормально:


Также у устройств появилась нормальная очередь NCQ глубиной 32.

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

Это был самый большой прирост производительности за всю диагностику.

После AHCI ZFS стал DEGRADED​

Но переключение SATA-контроллера привело к другому эффекту.

Linux изменил порядок обнаружения дисков.

До изменения режима диски имели одни имена:


После переключения на AHCI порядок поменялся.

В результате ZFS сначала импортировал пул в состоянии DEGRADED:


Физически накопитель никуда не исчезал.

Просто бывший /dev/sdc после изменения режима SATA стал другим устройством.

Определяю потерянный диск через ZFS label​

Я посмотрел ZFS label на диске:


Получил:


То есть ZFS однозначно показывал, что недостающий участник зеркала — Crucial BX500.

Проверка /dev/disk/by-id это подтвердила.

Перевожу ZFS на стабильные идентификаторы by-id​

Использовать /dev/sda, /dev/sdb и подобные имена для постоянной привязки дисков не очень удобно, потому что они могут поменяться после изменения контроллера, BIOS или порядка обнаружения устройств.

Поэтому я решил экспортировать пул и заново импортировать его через /dev/disk/by-id.

Сначала перевёл datastore PBS в offline maintenance:


Проверил, кто использует mountpoint:


После этого:


Посмотрел доступные пулы:


И импортировал:


После этого:


уже показывал диски через постоянные WWN:


После этого maintenance mode можно было убрать:


Пул снова стал:

Проверяю целостность ZFS с помощью scrub​

На BX500 ранее появился один исправленный ZFS checksum error.

Это ещё не означало неисправность самого SSD: ошибка была исправлена зеркалом, а данные приложений не пострадали.

Я сбросил старые счётчики:


и запустил полный scrub:


За процессом следил так:


Scrub завершился примерно за два часа:


То есть ZFS полностью прочитал пул и не обнаружил повреждённых данных.

После этого оснований считать BX500 неисправным уже не было.

Повторный тест после AHCI​

После перехода на AHCI картина изменилась кардинально.

Samsung, BX500 и MX500 стали показывать задержку записи приблизительно:


Но один накопитель продолжал заметно выделяться — SPCC Solid State Disk.

В некоторых интервалах:


На фоне остальных SSD это выглядело очень плохо.

Проверяю TRIM​

На пуле было:


Поэтому я решил выполнить полный ручной TRIM свободного пространства:


Проверить прогресс можно командой:


В моём случае TRIM занял несколько часов.

После завершения:


Ошибок ZFS при этом не было:

Что изменилось после TRIM​

На коротком тесте результат выглядел очень хорошо.

У SPCC задержка местами снизилась примерно с:


до:


А ZFS в отдельных burst-интервалах уже записывал более:


На первый взгляд могло показаться, что проблема решена.

Но короткого теста оказалось недостаточно.

Делаю длинный iostat​

Я запустил более продолжительное наблюдение во время реального backup:


И здесь SPCC снова проявил себя.

Во время реальной продолжительной нагрузки его задержки регулярно находились в районе:


а в отдельных интервалах доходили примерно до:


При этом скорость иногда составляла всего:


а %util уже находился около 100%.

Для сравнения Samsung 870 EVO и Crucial MX500 в тех же условиях обычно работали примерно с:


BX500 иногда проседал до нескольких миллисекунд, но его показатели всё равно были несопоставимо лучше SPCC.

То есть после длительного теста стало понятно: TRIM действительно дал некоторый эффект, но физическую проблему производительности SPCC он не устранил.

Проверяю SMART SPCC​

Следующим шагом:


На тот момент SPCC находился именно как /dev/sde.

SMART выглядел довольно чисто:


Температура:


Наработка:


Важный момент — SATA CRC errors отсутствовали:


В SATA Phy Event Counters также не было:


То есть явных признаков плохого SATA-кабеля не было.

Проверяю dmesg​

Я дополнительно посмотрел ошибки SATA:


SPCC нормально поднялся на SATA 3 Gbit/s:


При этом в журнале не было характерных сообщений:


Обнаруженные I/O error относились к fd0, то есть floppy device, и к SSD отношения не имели.

Почему только 3 Gbit/s, если SSD поддерживает SATA 6 Gbit/s​

SMART показывал:


Это нормально для используемого контроллера Intel ICH8.

Он ограничивает линк SATA скоростью 3 Gbit/s.

Но в моём случае это вообще не являлось причиной проблемы.

Даже SATA 3 Gbit/s позволяет передавать сотни мегабайт в секунду, а SPCC начинал упираться в 100% util уже на нескольких мегабайтах в секунду.

То есть ограничение было внутри самого SSD, а не в пропускной способности SATA.

Финальная проверка: переставляю SSD между SATA-портами​

Чтобы окончательно исключить SATA-порт, я физически переставил накопители между разъёмами материнской платы.

После перезагрузки Linux присвоил им такие имена:


То есть SPCC, который раньше был sde, после перестановки стал:


А BX500 занял его прежнее место и стал:


Это оказался самый важный эксперимент.

Проблема переехала вместе с SPCC​

Я снова запустил backup и:


Теперь уже sdd, то есть SPCC, показывал:


В ту же секунду BX500, который теперь находился на бывшем месте SPCC как sde, показывал:


В другом интервале:


То есть медленный накопитель физически переехал на другой SATA-порт — и проблема переехала вместе с ним.

ZFS подтверждает это по WWN​

Особенно полезно то, что ZFS идентифицирует диски не по меняющимся именам sda/sdb/sdd, а по WWN.

Для SPCC:


После перестановки портов в zpool iostat именно этот WWN снова отставал.

Например, в один из интервалов:


Это уже практически исключает влияние конкретного SATA-порта.

Итоговая привязка накопителей​

После финальной перестановки:

Что оказалось причиной​

В моём случае было две основные проблемы.

Первая и самая серьёзная — SATA-контроллер Intel работал в IDE mode.

После переключения на AHCI производительность дисковой подсистемы выросла в несколько раз.

Вторая проблема проявилась уже после исправления режима контроллера: один из четырёх SSD, SPCC Solid State Disk, оказался значительно медленнее остальных под продолжительной записью.

При этом:


То есть SSD не обязательно "мёртвый" в классическом понимании.

Он читает данные, SMART считается исправным и ошибок носителя нет.

Но его внутренняя производительность под длительной записью крайне нестабильна.

Вероятнее всего, узкое место находится внутри самого накопителя:


Для backup-хранилища такой SSD становится bottleneck всего mirror vdev.

Почему один медленный SSD влияет на ZFS mirror​

При записи в mirror данные должны попасть на оба накопителя зеркала.

Если один диск стабильно выполняет операции за:


а второй периодически за:


быстрый SSD не может полностью компенсировать медленный.

В результате появляются очереди, растёт I/O wait, а производительность всего vdev начинает зависеть от более медленного участника зеркала.

У меня это хорошо коррелировало с загрузкой CPU:

когда SPCC уходил к 100% util и большой w_await, системный %iowait поднимался примерно до:

Что в итоге я решил делать​

SPCC стал первым кандидатом на замену.

Для PBS и ZFS я бы предпочёл более предсказуемый TLC SSD с нормальным контроллером и хорошей устойчивой производительностью.

Из имеющихся у меня накопителей Samsung 870 EVO и Crucial MX500 показали себя значительно лучше.

BX500 также оказался заметно стабильнее SPCC, несмотря на то что сам относится к бюджетной линейке.

В идеале для серьёзного backup-хранилища я бы рассматривал enterprise/datacenter SSD с power-loss protection, но даже качественный consumer TLC SSD в данном случае будет огромным шагом вперёд по сравнению с проблемным SPCC.

Команды, которые оказались наиболее полезными​

Проверка задержек физических дисков:


Длительный тест:


Статистика ZFS:


Статус пула:


Проверка SATA-контроллера:


Информация о дисках:


Полный SMART:


Ошибки SATA:


Проверка ZFS label:


Scrub:


Ручной TRIM:

Несколько важных замечаний по оптимизации PBS + ZFS​

В процессе диагностики я сознательно не стал применять несколько популярных "ускорителей".

Не отключал sync:


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

Для backup-сервера такой компромисс мне не нравится.

Не отключал atime на datastore PBS.

Proxmox Backup Server использует время доступа к chunk-файлам при Garbage Collection, поэтому бездумно делать:


для PBS datastore не стоит.

Не использовал zpool upgrade ради производительности.

Сообщение:


само по себе не означает, что пул медленный.

zpool upgrade включает новые feature flags и может повлиять на совместимость пула со старыми версиями ZFS, но не является способом лечения высокой latency SSD.

Не стал сразу ставить SLOG.

SLOG помогает только определённому классу синхронных записей и не исправит SSD, который сам выполняет обычную запись с задержкой 50–200 ms.

Сначала всегда стоит найти физическое узкое место.

Что я вынес из этой диагностики​

Главный вывод — не стоит начинать оптимизацию ZFS с десятков sysctl, параметров ARC и опасных переключателей вроде sync=disabled.

Сначала нужно проверить самый нижний уровень:


В моём случае один взгляд на среднюю скорость не дал бы правильного ответа.

Именно w_await, aqu-sz, %util и сопоставление их с конкретными WWN позволили увидеть реальную проблему.

Особенно полезным оказался простой физический эксперимент: поменять два SSD местами.

Если проблема остаётся на порту — нужно искать контроллер, кабель или разъём.

Если проблема переезжает вместе с накопителем — виновник практически найден.

В моём случае произошло именно второе.

Результат​

После перехода:


производительность PBS выросла в несколько раз.

После полного ZFS scrub я убедился, что данные пула целы.

TRIM временно улучшил показатели отдельных SSD и показал, что состояние свободных NAND-блоков тоже влияло на производительность, однако длительный тест обнаружил оставшуюся проблему.

Финальная перестановка SATA-портов подтвердила:


является главным дисковым bottleneck моего ZFS-пула.

Следующий шаг — заменить этот SSD и после resilver повторить тот же длительный тест iostat, чтобы сравнить производительность до и после замены.