После апгрейда сервера с Intel Xeon на AMD EPYC мы обнаружили, что производительность в OLTP-бенчмарках упала на 15%. Причина — thermal throttling: старый кулер не справлялся с новым TDP, и процессор сбрасывал частоту. Стресс-тестирование помогло выявить проблему до ввода в production. Такие сценарии — не редкость: недогруженная система может скрывать дефекты охлаждения, нестабильность памяти или неоптимальные настройки дисков. В этой статье расскажем, как с помощью stress-ng, sysbench и fio провести комплексную проверку сервера и получить объективные метрики для принятия решений.
Какие инструменты и для чего?
| Инструмент | Назначение | Ключевые метрики | Типичное время теста |
|---|---|---|---|
| stress-ng | Стресс CPU, памяти, I/O, планировщика | bogo-ops/s, температура, throttling | 1-5 минут до теплового равновесия |
| sysbench | Бенчмарк CPU, памяти, файловой системы | events/s, throughput MiB/s, latency | 30-120 секунд |
| fio | Storage benchmark (IOPS, bandwidth, latency) | IOPS, BW, p99.9 latency | 60-300 секунд на тест |
Что такое 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)
- Рекомендации по доработке конфигурации (если нужно)
- Обучение вашей команды самостоятельному запуску
Типичные метрики для разных типов накопителей
| Тип накопителя | Random 4K IOPS | Sequential 1M BW | p99.9 latency (rand read) |
|---|---|---|---|
| NVMe SSD | 500k+ | 3-7 GB/s | <200 µs |
| SATA SSD | ~100k | ~500 MB/s | <1 ms |
| HDD | 100-200 | ~200 MB/s | >10 ms |
Сроки и стоимость
Разовое тестирование одного сервера по готовому сценарию — 2-4 часа. Разработка набора тестов и автоматизация приёмочного тестирования для парка серверов — от 1 до 2 дней. Стоимость рассчитывается индивидуально. Свяжитесь с нами для обсуждения вашего сценария — оценим проект и предложим план. За 5+ лет мы провели стресс-тестирование для 30+ инфраструктурных проектов, включая высоконагруженные системы под Kubernetes и СУБД. Стресс-тестирование помогает избежать затрат на замену оборудования на этапе эксплуатации, а экономия времени на диагностике достигает 40%.
Почему стоит заказать стресс-тестирование у нас?
Опыт с разными типами железа: NVMe, SATA SSD, HDD, NUMA, ARM. Автоматизируем процесс, чтобы можно было повторять регрессионные тесты. Гарантируем, что вы получите объективную картину производительности без «замыливания» кэшами ОС. Предоставляем детальный отчёт и консультацию по результатам. Получите консультацию — напишите нам, и мы подберём оптимальный набор тестов под вашу задачу.
