Как тестировать производительность RAID: fio, IOPS и задержки

Чек-лист перед RAID benchmark

• Есть актуальная и проверенная резервная копия затрагиваемых данных. RAID не заменяет резервное копирование: подробнее — Почему RAID — не резервное копирование: защита данных сервера.
• Массив находится в штатном состоянии: не деградирован, без предупреждений по дискам, контроллеру и защищённому кэшу.
• Не выполняются Rebuild, фоновая инициализация, Consistency Check или Patrol Read.
• Зафиксированы модель и прошивка контроллера, RAID-уровень, число и тип накопителей, размер stripe, политики чтения и записи, состояние защиты кэша, заполненность массива, версия ОС, ядра и fio.
• Выбран безопасный target: новый файл или отдельный пустой логический диск. Физический диск — участник действующего RAID — никогда не является target для теста производительности массива.
• На время теста отключены либо зафиксированы фоновые потребители: резервное копирование, индексация, репликация, антивирусная проверка, задачи СУБД, виртуальные машины и плановые операции хранения.

Что измеряют IOPS, bandwidth и задержки

IOPS — число завершённых операций ввода-вывода в секунду. Показатель полезен прежде всего для мелких операций фиксированного размера: например, случайного чтения по 4 KiB. Пропускная способность, которую fio обычно выводит как BW или bandwidth, показывает объём данных за секунду и важнее для последовательного чтения, резервного копирования, потоковой обработки и передачи больших файлов. Единицы нужно читать буквально: 1 MB равен 1 000 000 байт, а 1 MiB — 1 048 576 байтам. fio может показывать KiB/s, MiB/s и другие единицы, поэтому перед сравнением результаты приводят к одной системе.

Среднее значение скрывает редкие, но заметные паузы. Если p99 записи составляет десятки или сотни миллисекунд, а средняя задержка мала, пользователь или СУБД всё равно могут видеть зависания. Для потоковой передачи данных обычно первична устойчивая BW; для базы данных и хранилища ВМ нужны IOPS, задержки чтения и записи по отдельности, а также хвостовые перцентили.

Сначала опишите профиль нагрузки

RAID производительность не выражается одним числом. Последовательные и случайные операции, размер блока, доля чтения, глубина очереди, число параллельных потоков и размер рабочего набора меняют результат радикально. iodepth и numjobs описывают создаваемую нагрузку, а не «скорость массива». При асинхронном движке iodepth=1 ограничивает каждый job одним незавершённым I/O, но несколько job всё равно создают несколько одновременных запросов. Сочетание iodepth=1 и numjobs=1 показывает отклик при минимальном параллелизме, а более высокие значения — работу при одновременном наплыве запросов.

Для смешанной нагрузки rw=randrw задаёт случайное чтение и запись, а rwmixread=70 означает 70% операций чтения и 30% операций записи. Если в наблюдаемой нагрузке на запись приходится 20% операций ввода-вывода, не выбирайте 70% чтений только потому, что это распространённый пример. Размер рабочего набора size должен быть сопоставим с активными данными приложения; слишком малый файл легко полностью помещается в кэш или повторно обслуживается одними областями носителя.

Безопасный тест RAID через новый файл

mkdir -p /srv/fio-benchmark && df -h /srv/fio-benchmark && fio --version && fio --enghelp

set -euo pipefail

# Замените путь и размер после проверки каталога и свободного места.
TARGET=/srv/fio-benchmark/raid-bench-2026-09-25-01.dat
SIZE=100G

# Не разрешаем fio открыть и перезаписать уже существующий путь.
if [ -e "$TARGET" ] || [ -L "$TARGET" ]; then
    printf 'ОШИБКА: target уже существует: %s\n' "$TARGET" >&2
    exit 1
fi

# Полная подготовительная запись исключает чтение разрежённых или
# ещё не записанных областей. Это реальная нагрузка на весь диапазон SIZE.
fio --name=prepare-file \
    --filename="$TARGET" --size="$SIZE" \
    --rw=write --bs=1M --direct=1 \
    --ioengine=io_uring --iodepth=32 --numjobs=1 \
    --group_reporting=1 --output-format=json \
    --output=prepare-file.json

COMMON=(
    --filename="$TARGET"
    --size="$SIZE"
    --time_based=1
    --runtime=300
    --ramp_time=60
    --direct=1
    --ioengine=io_uring
    --iodepth=32
    --numjobs=1
    --group_reporting=1
    --randrepeat=0
    --output-format=json
)

# Последовательное чтение: 1 MiB
fio --name=seq-read "${COMMON[@]}" --rw=read --bs=1M \
    --output=seq-read.json

# Последовательная запись: 1 MiB; перезаписывает только тестовый файл
fio --name=seq-write "${COMMON[@]}" --rw=write --bs=1M \
    --output=seq-write.json

# Случайное чтение: 4 KiB
fio --name=rand-read-4k "${COMMON[@]}" --rw=randread --bs=4k \
    --output=rand-read-4k.json

# Случайная запись: 4 KiB; перезаписывает только тестовый файл
fio --name=rand-write-4k "${COMMON[@]}" --rw=randwrite --bs=4k \
    --output=rand-write-4k.json

# Смешанный профиль: 70% чтения, 30% записи
fio --name=rand-mix-4k "${COMMON[@]}" --rw=randrw --rwmixread=70 --bs=4k \
    --output=rand-mix-4k.json

time_based=1 заставляет fio выполнять нагрузку весь runtime, а не завершаться после однократного обхода size; ramp_time исключает начальный период из итоговой статистики. size=100G здесь одновременно задаёт рабочий диапазон файла и должен быть изменён под задачу. randrepeat=0 использует новый случайный шаблон между запусками; для строго повторяемого шаблона задайте фиксированный randseed и документируйте его.

direct=1 обычно запрашивает прямой I/O и уменьшает влияние page cache ОС, но его поведение зависит от ОС, файловой системы, драйвера и устройства. Это не универсальный обход всех кэшей: RAID-кэш, кэш контроллера накопителя и внутренние механизмы SSD остаются в пути. Не очищайте page cache штатной командой на рабочем сервере ради benchmark: это меняет состояние всей системы и может повлиять на сервисы.

Разрушающий тест выделенного логического диска

Пустой выделенный логический диск позволяет измерить блочный путь без влияния файловой системы. Это может быть отдельный Virtual Disk аппаратного RAID-контроллера или отдельное устройство программного RAID. Такой тест отвечает на другой вопрос, чем файл: он не отражает накладные расходы конкретной файловой системы, LVM, CoW или монтирования.

# Подставьте только заранее подтверждённый устойчивый путь.
TARGET=/dev/disk/by-id/scsi-EXAMPLE_EMPTY_LOGICAL_DISK
DEV=$(readlink -f "$TARGET")

printf 'Target: %s -> %s\n' "$TARGET" "$DEV"
lsblk -o NAME,KNAME,TYPE,SIZE,FSTYPE,FSVER,LABEL,UUID,MOUNTPOINTS,PKNAME "$DEV"
findmnt -S "$DEV"
ls -la "/sys/class/block/$(basename "$DEV")/holders"
blkid "$DEV"
wipefs -n "$DEV"
cat /proc/mdstat

# Если используются device-mapper, LVM или multipath, проверьте также:
dmsetup ls --tree
pvs -o pv_name,vg_name,pv_size,pv_free

# ВНИМАНИЕ: следующие команды РАЗРУШАЮЩИЕ.
# Выполняйте только на подтверждённом пустом выделенном логическом диске.
TARGET=/dev/disk/by-id/scsi-EXAMPLE_EMPTY_LOGICAL_DISK
COMMON="--filename=$TARGET --size=100% --time_based=1 --runtime=900 --ramp_time=120 --direct=1 --ioengine=io_uring --iodepth=32 --numjobs=1 --group_reporting=1 --randrepeat=0 --output-format=json"

# Чтение без изменения содержимого устройства
fio --name=block-rand-read-4k $COMMON --rw=randread --bs=4k --output=block-rand-read-4k.json

# РАЗРУШАЮЩАЯ случайная запись по адресам во всём диапазоне target
fio --name=block-rand-write-4k $COMMON --rw=randwrite --bs=4k --output=block-rand-write-4k.json

# РАЗРУШАЮЩАЯ последовательная запись в течение runtime.
# Если времени недостаточно, fio может не пройти target целиком.
fio --name=block-seq-write $COMMON --rw=write --bs=1M --output=block-seq-write.json

Параметр invalidate=1 можно документированно добавлять в сценарии, где он поддерживается используемым движком и ОС: fio будет пытаться инвалидировать кэшированные данные файла перед запуском job. Он не заменяет direct=1, не очищает кэш всего сервера и не управляет кэшами RAID или SSD. Значения direct, invalidate, group_reporting, size, runtime, ramp_time и формат JSON сверяйте с fio --help и документацией установленной fio.

Кэши и устойчивая скорость записи

Краткий тест может измерить скорость принятия данных в RAM page cache, защищённый Write-Back кэш RAID-контроллера или SLC-кэш SSD, а не длительную скорость носителей. При исправной BBU, CacheVault или суперконденсаторе контроллер может подтверждать запись после помещения данных в защищённый кэш; при проблеме с защитой многие контроллеры переключаются в кэш со сквозной записью. Конкретная политика перехода определяется моделью и прошивкой контроллера.

• Отделяйте burst от устойчивого результата: запускайте запись достаточно долго, стройте latency/BW-логи и проверяйте, переходит ли скорость и задержка после начального периода к другому устойчивому уровню.
• Для проверки кэша чтения используйте рабочий набор больше кэша, влияние которого требуется оценить. Для Write-Back и SLC-кэша одного большого рабочего диапазона недостаточно: важны длительность, объём фактически записанных данных и изменение BW и задержек во времени.
• Сравнивайте несколько запусков после одинакового состояния массива, а не один «лучший» результат.
• Для SSD фиксируйте заполненность и свободное пространство, состояние и время последнего discard/TRIM, температуру, предыдущую нагрузку, период простоя и условия фоновой сборки мусора. Сравнивайте накопители после одинаковой подготовки: garbage collection может продолжаться внутри SSD и менять скорость и задержки без видимого процесса в ОС.
• Не называйте любой результат после короткого ramp_time steady state: короткий прогрев может не исчерпать кэш контроллера или SLC-кэш SSD.

Предварительная полная запись иногда нужна в лабораторной методике, чтобы привести SSD к определённому состоянию перед сравнением. Но это разрушающая операция, она стирает прежнее содержимое target, вызывает дополнительный износ SSD и не должна быть обязательным шагом для рабочего массива. Метод, объём и длительность preconditioning выбирают под цель измерения и рекомендации производителя накопителей.

Если нужно моделировать подтверждённую устойчивую запись приложения, одной команды rw=write недостаточно: она может измерять передачу данных до нижележащего кэша. fio поддерживает механизмы вроде fsync, fdatasync и end_fsync, но их семантика зависит от ОС, файловой системы и стека хранения. Настраивайте их только как часть профиля приложения: например, если СУБД действительно делает fsync для журнала. Не добавляйте fsync в тест пропускной способности файлового сервера без причины.

Как читать вывод fio

В текстовом и JSON-выводе fio обычно публикует статистику чтения и записи отдельно. Для последовательного профиля сначала смотрите BW и его стабильность во времени; для randread или randwrite с блоком 4 KiB — IOPS и задержки. При group_reporting=1 fio агрегирует результаты job в отчёт группы, что удобно для общей нагрузки, но скрывает разброс между отдельными потоками.

Почему RAID 5 и RAID 6 могут медленно писать мелкие блоки

В RAID 5 и RAID 6 частичная запись, не закрывающая всю полосу RAID, нередко приводит к циклу чтение-модификация-запись: нужно учесть прежние данные и контрольную информацию, пересчитать чётность и записать обновления. Поэтому мелкая случайная запись может создавать больше внутренней работы, чем чтение или последовательная запись.

Часто приводимый фиксированный «write penalty» — лишь упрощённая модель, а не точный прогноз IOPS. Реальный эффект меняется с размером I/O, выравниванием, числом дисков с данными, кэшем контроллера, политикой записи, накопителями и тем, удаётся ли контроллеру объединить операции в полную полосовую запись. Для конкретной реализации размер полной полосы обычно равен размеру элемента полосы на одном диске — strip или chunk — умноженному на число дисков с данными в полосе. Контроллеры могут называть размер элемента или всей полосы Stripe Size, поэтому значение нужно сверять с документацией конкретной реализации.

• Измерьте мелкую случайную запись отдельно с bs=4k, 8k и 16k, если эти размеры соответствуют приложению.
• Для проверки эффекта полной полосы сначала вычислите её точный размер. Используйте I/O такого размера только при подтверждённом выравнивании начала устройства, раздела, файловой системы и смещений fio по границе полосы; размер, лишь близкий к полной полосе, полнополосную запись не гарантирует.
• Сравните выровненный полнополосный профиль с обычным профилем приложения. Не подменяйте профиль приложения крупными блоками только ради более высокой цифры.
• Сравните QD1 и рабочую для приложения очередь: кэш может по-разному объединять операции.
• Повторите тесты с документированными политиками Write Back и Write Through, только если Write Back действительно защищён.
• Не выводите пригодность RAID 5/6 из одного коэффициента. Для настройки кэша и Stripe Size см. Кэш RAID-контроллера, Write Back и Stripe Size: выбор без лишнего риска.

Как решить, хватает ли результата реальной нагрузке

1. Сопоставьте каждый fio-профиль с измерениями приложения: размер I/O, read/write ratio, параллелизм, активный набор данных и требования к подтверждённой записи.
2. Проверьте, что средние IOPS и bandwidth достаточны, а p95/p99/p99.9 задержек укладываются в допустимую реакцию сервиса.
3. Заложите обоснованный запас на рост нагрузки, фоновые задачи, заполнение SSD и изменение состояния кэшей.
4. Отдельно оцените эксплуатационные сценарии деградации и Rebuild по документации и, если возможно, на стенде. Не переводите рабочий массив в деградированное состояние ради обычного benchmark.
5. Подтвердите вывод нагрузочным тестом фактического потребителя: СУБД, datastore гипервизора, файлового сервера или другого приложения.

В отчёте по raid тесту производительности сохраните команды fio и JSON, версию fio и ioengine, runtime, ramp_time, size, bs, iodepth, numjobs, состояние массива до и после теста, заполненность, политики кэшей, состояние SSD и сведения о фоновых процессах. Это позволяет повторить измерение и объяснить разницу результатов, а не сравнивать несопоставимые цифры.