Бенчмарк выделенного сервера: fio, sysbench, iperf3

Диски измеряют утилитой fio с прямым вводом-выводом и профилем, похожим на вашу нагрузку; процессор и память — sysbench; канал — iperf3 до узла в той же стране. Замеры делают до переноса проекта, на пустом сервере, и сохраняют как эталон: без базовой цифры любая будущая жалоба на «сервер тормозит» неразрешима.

fio без --direct=1 измеряет страничный кэш ядра и показывает фантастические числа, не связанные с диском.
Тестовый файл должен быть больше объёма оперативной памяти минимум вдвое, иначе данные осядут в кэше.
Случайная запись блоком 4k — единственная цифра, которая предсказывает поведение СУБД.

Подготовка: что сделать до первого теста

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

# Debian/Ubuntu
apt-get install -y fio sysbench iperf3 ioping hdparm
# RHEL, AlmaLinux, Rocky
dnf install -y epel-release
dnf install -y fio sysbench iperf3 ioping hdparm

# массив не в ребилде и не деградировал
cat /proc/mdstat

Диски: fio

Четыре профиля закрывают практически все задачи. Случайное чтение и запись блоком 4k моделируют базу данных, последовательные — бэкап и выдачу видео.

# случайное чтение 4k, глубина очереди 32
fio --name=randread --filename=/mnt/test/fio.tmp --size=32G \
    --rw=randread --bs=4k --iodepth=32 --numjobs=4 --direct=1 \
    --ioengine=libaio --runtime=120 --time_based --group_reporting

# случайная запись 4k — главная цифра для СУБД
fio --name=randwrite --filename=/mnt/test/fio.tmp --size=32G \
    --rw=randwrite --bs=4k --iodepth=32 --numjobs=4 --direct=1 \
    --ioengine=libaio --runtime=120 --time_based --group_reporting

# смешанная нагрузка 70/30 с отчётом по задержкам
fio --name=mixed --filename=/mnt/test/fio.tmp --size=32G \
    --rw=randrw --rwmixread=70 --bs=4k --iodepth=16 --numjobs=4 \
    --direct=1 --ioengine=libaio --runtime=180 --time_based \
    --group_reporting --percentile_list=50:95:99:99.9 2>&1 | tee fio-mixed.log

Смотрите не на среднюю скорость, а на IOPS и на перцентили задержки. Средняя задержка 0,3 мс при 99-м перцентиле 40 мс означает регулярные подвисания, которые пользователь заметит, а среднее — нет. Быстрый контроль задержки без нагрузки даёт ioping -c 20 /mnt/test.

Процессор и память: sysbench

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

# один поток: сравнение per-core производительности
sysbench cpu --cpu-max-prime=20000 --threads=1 --time=60 run

# все ядра
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) --time=60 run

# пропускная способность памяти на запись
sysbench memory --memory-block-size=1M --memory-total-size=100G \
    --memory-oper=write --threads=$(nproc) run

Канал: iperf3

Канал меряют до публичного сервера iperf3 в той же стране, что и площадка. Один поток почти никогда не выбирает гигабит, поэтому запускают 8 и больше параллельных соединений.

# приём: 8 потоков, 30 секунд
iperf3 -c SERVER -P 8 -t 30

# отдача с сервера в вашу сторону
iperf3 -c SERVER -P 8 -t 30 -R

Полученное число сверяйте с характеристикой тарифа: на выделенных серверах ZevsHost базовые конфигурации в Германии идут на 100 Мбит/с, во Франции — 500 Мбит/с, конфигурации Pro и Enterprise — 1 Гбит/с. Что означают unlimited и лимит в 30 ТБ, разобрано в статье про канал сервера и трафик.

Что чем измерять

Подсистема	Инструмент	Ключевая метрика	Когда цифра плохая
Диск, случайная нагрузка	fio randread/randwrite 4k	IOPS и задержка на 99-м перцентиле	NVMe отдаёт менее 50 000 IOPS на чтение
CPU, один поток	sysbench cpu --threads=1	events per second	расхождение с эталоном более 15%
CPU, все ядра	sysbench cpu --threads=nproc	events per second	масштабирование хуже 60% от числа ядер
Канал	iperf3 -P 8	Гбит/с в обе стороны	менее 80% заявленной полосы

Параметр --filename в fio принимает и блочное устройство. Указав --filename=/dev/sdb с профилем записи, вы затрёте разделы и данные на этом диске без единого вопроса, а на зеркале изменение уедет сразу на оба накопителя. Всегда тестируйте через файл внутри смонтированной файловой системы: mkdir -p /mnt/test и --filename=/mnt/test/fio.tmp. Второй источник мусорных цифр — тест поверх идущего ребилда или живого продакшена: перед запуском убедитесь, что cat /proc/mdstat не содержит строки recovery, а vmstat 1 5 показывает id около 100. Как устроен ребилд, описано в статье про замену диска в массиве.

Как интерпретировать результат

Цифры читают в сравнении с эталоном той же машины.

Проседание случайной записи в разы при нормальном чтении — обычно кэш контроллера ушёл в write-through или SSD исчерпал SLC-буфер.
CPU в один поток ниже эталона при нормальном многопоточном — включённое энергосбережение или ограничение частоты в прошивке.

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

Коротко

fio всегда с --direct=1 и файлом вдвое больше объёма оперативной памяти.
Главная дисковая метрика для базы данных — IOPS на случайной записи 4k и 99-й перцентиль задержки.
Бенчмарк без сохранённого эталона теряет смысл: снимайте базовые значения на пустом сервере.