Стрес-тестування серверів stress-ng, sysbench, fio

Після апгрейду сервера з Intel Xeon на AMD EPYC ми виявили, що продуктивність в OLTP-бенчмарках впала на 15%. Причина — thermal throttling: старий кулер не справлявся з новим TDP, і процесор скидав частоту. Стрес-тестування допомогло виявити проблему до введення в production. Такі сценарії — не рідкість: недовантажена система може приховувати дефекти охолодження, нестабільність пам'яті або неоптимальні налаштування дисків. У цій статті розповімо, як за допомогою stress-ng, sysbench і fio провести комплексну перевірку сервера та отримати об'єктивні метрики для прийняття рішень.

Які інструменти та для чого?

Що таке bogo-ops/s і чи варто на нього орієнтуватися?

bogo-ops/s — внутрішня метрика stress-ng, яка показує кількість виконаних операцій за секунду. Вона корисна для відносного порівняння двох конфігурацій (наприклад, до та після заміни термопасти), але не дає абсолютного еталону. Для точних вимірювань використовуйте sysbench.

Як stress-ng виявляє thermal throttling?

stress-ng — швейцарський ніж стрес-тестування: 300+ типів стрессорів. За словами автора stress-ng Коліна Іана Кінга, інструмент нараховує понад 300 стрессорів. На відміну від burnP6, він вміє навантажувати конкретні інструкції процесора, викликати конкуренцію за пам'ять та перевіряти thermal throttling.

# Стрес всіх CPU-ядер через 60 секунд
stress-ng --cpu 0 --cpu-method matrixprod --timeout 60s --metrics-brief

# CPU + пам'ять одночасно
stress-ng --cpu 4 --vm 2 --vm-bytes 2G --timeout 120s

# Тест під thermal throttling (+ моніторинг температури)
stress-ng --cpu 0 --timeout 300s & watch -n1 "sensors | grep 'Core|Package'"

# Стресор для тестування планувальника ОС
stress-ng --sched 4 --timeout 60s --metrics-brief

--cpu 0 — використовувати всі доступні ядра. --cpu-method matrixprod — операції з матрицями, добре навантажують FPU та кеші. Прапорець --metrics-brief в кінці виводить bogo-ops/s — не абсолютна метрика, але зручна для порівняння конфігурацій.

sysbench: OLTP-навантаження та benchmark пам'яті

sysbench історично використовують для MySQL/PostgreSQL benchmarking, але тести CPU та memory також корисні:

# CPU тест (обчислення простих чисел)
sysbench cpu --cpu-max-prime=20000 --threads=8 run

# Memory bandwidth тест
sysbench memory --memory-block-size=1K --memory-total-size=10G \
  --memory-oper=write --threads=8 run

# Тест випадкового читання/запису файлової системи
sysbench fileio --file-total-size=10G prepare
sysbench fileio --file-total-size=10G --file-test-mode=rndrw \
  --time=120 --max-requests=0 --threads=4 run
sysbench fileio --file-total-size=10G cleanup

Вивід sysbench memory покаже memory throughput в MiB/s. Типові значення: DDR4-3200 dual-channel дають ~40-50 GB/s теоретично, реальний sysbench показує 20-30 GB/s залежно від патерну доступу.

fio: серйозне тестування дискової підсистеми

fio — стандарт для storage benchmarking. Параметрів багато, але головні:

# nvme-test.fio
[global]
ioengine=libaio
direct=1
numjobs=4
runtime=60
group_reporting

[seq-read]
rw=read
bs=1M
size=10G
filename=/dev/nvme0n1

[rand-4k-read]
rw=randread
bs=4k
size=4G
iodepth=32
filename=/dev/nvme0n1

[rand-4k-write]
rw=randwrite
bs=4k
size=4G
iodepth=32
filename=/dev/nvme0n1

fio nvme-test.fio 

Критичні метрики у виводі fio:

• IOPS — для random 4K: хороший NVMe SSD дасть 500k+ IOPS, SATA SSD — ~100k, HDD — 100-200
• BW (bandwidth) — для sequential 1M: NVMe — 3-7 GB/s, SATA SSD — ~500 MB/s
• lat (latency) — avg та p99.9: для NVMe random read p99.9 повинен бути <200µs, для SATA SSD <1ms

iodepth=32 — глибина черги. Для SSD/NVMe збільшуйте до 64-128 для максимального throughput. direct=1 — обхід page cache, тестуємо залізо, а не кеш ОС.

Додаткові параметри fio для глибокого аналізу: для вимірювання затримок з високим процентилем додайте --lat_percentiles=1 та --percentile_list=50:90:99:99.9. Також корисний --write_lat_log для детального логу.

Як провести комплексний стрес-тест перед введенням в production?

Типовий приймальний сценарій — три фази:

#!/bin/bash
# Фаза 1: прогрів 10 хвилин під повним навантаженням
stress-ng --cpu 0 --vm 4 --vm-bytes 1G --io 4 --timeout 600s \
  --metrics-brief 2>&1 | tee /tmp/stress-report.txt

# Фаза 2: disk I/O benchmark
fio --name=acceptance-test --ioengine=libaio --direct=1 \
  --rw=randrw --rwmixread=70 --bs=4k --numjobs=4 \
  --size=8G --runtime=120 --time_based \
  --filename=/var/lib/test-fio.dat \
  --group_reporting 2>&1 | tee /tmp/fio-report.txt

# Фаза 3: memory bandwidth
sysbench memory --memory-block-size=1M --memory-total-size=50G \
  --threads=$(nproc) run 2>&1 | tee /tmp/sysbench-report.txt

echo "Acceptance test complete. Reports in /tmp/"

Під час фази 1 моніторимо температуру CPU (sensors), throttling (dmesg | grep -i throttl), частоту ядер (cpupower frequency-info). Якщо сервер throttles при 80% навантаженні — проблема охолодження, яку краще знайти зараз.

Що входить у послугу з налаштування стрес-тестування

• Підбір сценаріїв під ваше залізо: CPU, RAM, диск, мережа
• Підготовка та запуск тестів з автоматичним збором метрик
• Аналіз результатів: виявлення вузьких місць, порівняння з еталоном
• Звіт з графіками (температура, частоти, IOPS, latency)
• Рекомендації щодо доопрацювання конфігурації (якщо потрібно)
• Навчання вашої команди самостійному запуску

Типові метрики для різних типів накопичувачів

Строки та вартість

Разове тестування одного сервера за готовим сценарієм — 2-4 години. Розробка набору тестів та автоматизація приймального тестування для парку серверів — від 1 до 2 днів. Вартість розраховується індивідуально. Зв'яжіться з нами для обговорення вашого сценарію — підготуємо оцінку проєкту. За 5+ років ми провели стрес-тестування для 30+ інфраструктурних проєктів, включаючи високонавантажені системи під Kubernetes та СУБД. Стрес-тестування допомагає уникнути витрат на заміну обладнання на етапі експлуатації, а економія часу на діагностиці досягає 40%.

Чому варто замовити стрес-тестування у нас?

Досвід з різними типами заліза: NVMe, SATA SSD, HDD, NUMA, ARM. Автоматизуємо процес, щоб можна було повторювати регресійні тести. Гарантуємо, що ви отримаєте об'єктивну картину продуктивності без «замилювання» кешами ОС. Надаємо детальний звіт та консультацію за результатами. Отримайте консультацію — напишіть нам, і ми підберемо оптимальний набір тестів під вашу задачу.

Чек-лист: типові помилки при стрес-тестуванні

• Тестування без моніторингу температури — пропускаєте thermal throttling.
• Використання лише одного інструменту — stress-ng без fio не покаже реальних IOPS диска.
• Занадто короткі тести (<5 хв) — не виявляють проблем з перегрівом або накопиченням помилок.
• Забудьте про direct=1 у fio — отримаєте занижені latency через кеш ОС.
• Не перевіряйте NUMA-балансування для багатопроцесорних систем — ризик нерівномірного навантаження.

Наші спеціалісти допоможуть уникнути цих помилок та забезпечити об'єктивні результати.