stress-ng: как устроить серверу стресс-тест

stress-ng — утилита для стресс-тестирования Linux-сервера: CPU, памяти, диска, планировщика, сокетов, файловой системы и десятков других подсистем. Её используют, чтобы проверить запас по ресурсам, воспроизвести деградацию, прогреть мониторинг, протестировать лимиты контейнеров или понять, как приложение ведёт себя рядом с «шумным соседом».

Главное отличие stress-ng от HTTP-нагрузчиков вроде wrk, ab или k6: она нагружает не ваш API напрямую, а саму машину. Можно отдельно «забить» процессор, съесть память, создать I/O pressure, поднять load average, проверить реакцию systemd, cgroups, OOM Killer и алертов. Это полезно не вместо нагрузочного тестирования приложения, а рядом с ним.

Ниже — практический разбор stress-ng: как установить утилиту, какие команды запускать, как не положить сервер и на какие метрики смотреть во время теста.

Что такое stress-ng и когда он нужен

stress-ng — развитие старой утилиты stress. Она содержит большой набор так называемых stressors — модулей нагрузки. Каждый stressor создаёт определённый тип давления на систему: вычисления, выделение памяти, запись на диск, переключение контекста, создание процессов, работу с сокетами, блокировки, таймеры, файловые операции.

Типовые задачи:

1) Проверить запас CPU — понять, как сервис ведёт себя, когда соседний процесс забирает несколько ядер. Частый сценарий на VPS, shared-хостингах, CI-раннерах и серверах с несколькими приложениями.

2) Воспроизвести нехватку памяти — безопасно подвести машину к memory pressure и посмотреть, начнутся ли swap, OOM, рестарты сервисов, рост latency.

3) Проверить дисковую подсистему — создать интенсивную запись/чтение и увидеть, как база данных, очередь или логирование реагируют на I/O wait.

4) Протестировать мониторинг и алерты — нагрузка должна отражаться в метриках, графиках и уведомлениях. Если CPU 100%, а алерт молчит, проблема не в сервере, а в настройках наблюдаемости.

5) Проверить лимиты контейнеров и systemd-сервисов — убедиться, что приложение не выходит за заданные CPU/memory-границы и корректно ограничивается cgroups.

При этом stress-ng не отвечает на вопрос «сколько пользователей выдержит сайт». Для этого нужны HTTP-нагрузчики и сценарные тесты. Если вам нужно давить именно endpoint'ы, посмотрите материалы про wrk и ab или k6. stress-ng отвечает на другой вопрос: «что будет с сервером и приложениями, если один из ресурсов станет узким местом».

Безопасность перед запуском

stress-ng легко превращает рабочую машину в недоступную. Особенно опасны тесты памяти и диска: можно вызвать OOM, забить файловую систему временными файлами, спровоцировать рост latency у базы или получить cascade failure у зависимых сервисов.

Перед первым запуском стоит пройти короткий чеклист.

1) Запускайте тесты сначала на staging — идеальный вариант: копия продакшен-сервера с похожими лимитами, ядром, дисками и контейнерной конфигурацией. Если staging нет, начинайте с минимальных значений и короткого --timeout.

2) Всегда задавайте время теста — используйте --timeout 30s, --timeout 2m, --timeout 10m. Не запускайте стрессоры «до Ctrl+C» на удалённой машине, к которой можно потерять SSH-доступ.

3) Оставляйте запас ресурсов — не начинайте с --cpu 0 и --vm-bytes 100%. Для первых тестов достаточно 50–70% CPU и памяти. В продакшене — ещё меньше.

4) Следите за метриками в отдельной сессии — откройте htop, vmstat, iostat, sar, journalctl, графики Prometheus/Grafana или другой мониторинг. Если нужно освежить базовые инструменты, пригодятся статьи про htop, vmstat и sar, iostat и iotop.

5) Подготовьте способ остановки — держите вторую SSH-сессию, доступ к консоли провайдера, tmux или screen. Если запускаете тест как systemd-юнит, заранее проверьте systemctl stop.

6) Не тестируйте диск без понимания пути — по умолчанию временные файлы могут попасть туда, где у вас /tmp, а он иногда расположен на корневом разделе. Для I/O-тестов лучше явно указывать временную директорию на нужном диске.

Если проверяете рабочий сайт, полезно параллельно включить внешний мониторинг доступности: например, Statuser будет проверять URL с заданным интервалом и пришлёт уведомление, если сайт перестанет отвечать. Это помогает увидеть не только локальные метрики, но и реальное поведение снаружи.

Установка stress-ng

В большинстве дистрибутивов stress-ng есть в стандартных репозиториях.

Для Ubuntu и Debian:

sudo apt update
sudo apt install stress-ng

Для Fedora:

sudo dnf install stress-ng

Для RHEL-подобных систем пакет может быть доступен через EPEL:

sudo dnf install epel-release
sudo dnf install stress-ng

Для Arch Linux:

sudo pacman -S stress-ng

Проверить версию:

stress-ng --version

Посмотреть список доступных stressors можно во встроенной справке:

stress-ng --help

Справка большая, но полезная:

man stress-ng

Если пакет в репозитории старый, можно собрать свежую версию из исходников, но для большинства задач хватает системного пакета. Важно другое: тесты должны быть воспроизводимыми. Записывайте версию stress-ng, команду, параметры сервера, лимиты контейнера и состояние нагрузки до запуска.

Базовый синтаксис команды

Минимальная команда выглядит так:

stress-ng --cpu 2 --timeout 60s --metrics-brief

Она запускает два CPU-stressor'а на 60 секунд и в конце выводит краткие метрики.

Основные элементы команды:

1) Stressor — что именно нагружать. Например, --cpu, --vm, --hdd, --io, --matrix, --fork, --sock.

2) Количество workers — число рабочих процессов или потоков для stressor'а. Например, --cpu 4 запустит четыре CPU workers.

3) Ограничение по времени — --timeout 30s, --timeout 5m, --timeout 1h.

4) Интенсивность и параметры — зависят от stressor'а: --vm-bytes, --hdd-bytes, --cpu-load, --temp-path.

5) Отчёт — --metrics-brief показывает краткую сводку, --times добавляет пользовательское и системное время.

Пример с более подробным выводом:

stress-ng --cpu 4 --cpu-method matrixprod --timeout 2m --metrics-brief --times

Полезные общие опции:

1) --dry-run — проверить, что команда корректна, без запуска нагрузки.

stress-ng --cpu 4 --timeout 60s --dry-run

2) --verify — включить проверки корректности там, где stressor это поддерживает. Полезно для тестов памяти и вычислений, но может менять профиль нагрузки.

stress-ng --cpu 4 --verify --timeout 60s

3) --verbose — больше информации во время выполнения.

stress-ng --vm 2 --vm-bytes 512M --timeout 60s --verbose

4) --metrics-brief — почти всегда стоит включать, чтобы получить сводку по bogo operations (подробнее о том, как её читать, — в разделе «Как читать результаты и метрики»).

Нагрузка на CPU

CPU-тесты — самый безопасный старт. Они редко портят данные и обычно быстро прекращаются после завершения процесса. Но на продакшене даже CPU pressure может вызвать рост latency, таймауты, 502/503 от прокси и проблемы с фоновыми задачами.

Нагрузить все доступные CPU:

stress-ng --cpu 0 --timeout 60s --metrics-brief

--cpu 0 означает «по числу доступных CPU». Для осторожного теста лучше указать конкретное число:

stress-ng --cpu 2 --timeout 60s --metrics-brief

Ограничить загрузку примерно до 50% на workers:

stress-ng --cpu 4 --cpu-load 50 --timeout 2m --metrics-brief

Выбрать метод вычислений:

stress-ng --cpu 4 --cpu-method fft --timeout 60s --metrics-brief

Список CPU-методов можно посмотреть так:

stress-ng --cpu-method which

Практические сценарии:

1) Проверка реакции приложения на CPU saturation — запустите stress-ng --cpu N, где N меньше числа ядер, и параллельно сделайте несколько запросов к API. Смотрите p95/p99 latency, ошибки, очередь запросов, event loop lag для Node.js или GC-паузы для Go/Java.

2) Проверка autoscaling или лимитов — если сервис в контейнере имеет CPU limit, запустите stress-ng внутри контейнера и снаружи. Сравните, где именно возникает throttling.

3) Проверка планировщика и load average — CPU-тесты быстро поднимают load average, но интерпретировать его нужно с учётом числа ядер и I/O wait. Подробнее об этом — в статье что такое load average в Linux.

Команда для наблюдения рядом:

vmstat 1

Смотрите на us, sy, id, wa, r. Если r стабильно выше числа CPU, процессы ждут выполнения. Если растёт wa, проблема уже не только в CPU, а в диске.

Нагрузка на память и OOM

Тесты памяти требуют осторожности. Если выделить слишком много RAM, ядро начнёт активно использовать swap, затем может сработать OOM Killer. Иногда это ровно то, что нужно проверить, но делать это лучше в контролируемой среде.

Базовый тест памяти:

stress-ng --vm 2 --vm-bytes 512M --timeout 60s --metrics-brief

Здесь запускаются два memory workers, каждый использует до 512M.

Использовать процент от доступной памяти:

stress-ng --vm 2 --vm-bytes 60% --timeout 2m --metrics-brief

Сохранить выделенную память, не освобождая её между итерациями:

stress-ng --vm 1 --vm-bytes 1G --vm-keep --timeout 60s --metrics-brief

Проверить разные методы работы с памятью:

stress-ng --vm 2 --vm-bytes 50% --vm-method all --timeout 2m --metrics-brief

Что смотреть:

1) free -h — общий баланс RAM/swap.

watch -n 1 free -h

2) vmstat 1 — поля si и so показывают swap in/out. Если они растут, система активно ходит в swap.

3) dmesg и journalctl — признаки OOM, убийства процессов, ошибки аллокации.

journalctl -k -f

4) Метрики приложения — latency, ошибки, рестарты, GC, использование heap.

Если тестируете защиту от OOM, заранее разберитесь, какие процессы имеют высокий oom_score, какие лимиты заданы в cgroups и что должен делать supervisor. Хороший контекст есть в статье про OOM Killer в Linux.

На рабочем сервере не стоит запускать --vm-bytes 90% без крайней необходимости. Даже если OOM не случится, кэш файловой системы будет вытеснен, и после теста приложение может временно работать медленнее из-за холодного cache.

Диск, I/O wait и файловая система

Дисковые тесты помогают найти проблемы, которые не видны при обычной CPU-нагрузке: рост iowait, задержки записи логов, деградацию базы, медленные fsync, переполнение очереди блочного устройства.

Простой тест записи:

stress-ng --hdd 2 --hdd-bytes 1G --timeout 2m --metrics-brief

Указать временную директорию:

mkdir -p /mnt/testdisk/stress-ng
 
stress-ng --hdd 2 --hdd-bytes 2G --temp-path /mnt/testdisk/stress-ng --timeout 3m --metrics-brief

Комбинировать I/O stressor:

stress-ng --io 4 --timeout 60s --metrics-brief

--hdd создаёт файловую нагрузку, а --io нагружает операции ввода-вывода через системные вызовы. Профиль у них разный, поэтому для диагностики полезно запускать оба, но не обязательно одновременно.

Что контролировать:

1) Свободное место — до и после теста.

df -h

2) I/O latency и загрузку устройств — через iostat.

iostat -xz 1

Смотрите на await, %util, r/s, w/s, rkB/s, wkB/s. Высокий %util не всегда означает проблему, но вместе с ростом await и latency приложения это сильный сигнал.

3) Процессы, которые создают I/O — через iotop.

sudo iotop -o

4) Логи ядра — ошибки диска, файловой системы, timeouts.

journalctl -k -f

Если рядом работает база данных, дисковый стресс может резко испортить tail latency. Особенно чувствительны PostgreSQL/MySQL при частых fsync, чекпоинтах, нехватке кэша и конкуренции за один том. Для отдельного теста скорости диска лучше использовать специализированную утилиту fio; про неё есть подробный материал fio: тест скорости диска. stress-ng удобнее именно для имитации давления на систему, а не для точного бенчмарка накопителя.

Комбинированные сценарии

Реальные инциденты редко упираются в один ресурс. Часто CPU, память и диск деградируют вместе: процесс съедает RAM, начинается swap, растёт I/O wait, воркеры не успевают отвечать, прокси возвращает 502/504. stress-ng позволяет собрать такой сценарий одной командой.

Осторожный смешанный тест:

stress-ng \
  --cpu 2 --cpu-load 70 \
  --vm 1 --vm-bytes 512M \
  --hdd 1 --hdd-bytes 1G \
  --timeout 2m \
  --metrics-brief

Более жёсткий тест для staging:

stress-ng \
  --cpu 0 \
  --vm 2 --vm-bytes 70% --vm-keep \
  --io 4 \
  --timeout 5m \
  --metrics-brief --times

Тест на создание процессов:

stress-ng --fork 4 --timeout 60s --metrics-brief

Тест сокетов:

stress-ng --sock 4 --timeout 60s --metrics-brief

Тест матричных вычислений:

stress-ng --matrix 4 --timeout 60s --metrics-brief

Хороший подход — не запускать «всё сразу», а идти ступенями:

1) Базовая линия — 5–10 минут без искусственной нагрузки. Зафиксируйте CPU, RAM, disk I/O, latency, error rate, число запросов, состояние очередей.

2) Один ресурс — отдельно CPU, отдельно память, отдельно диск. Так проще понять чувствительность приложения.

3) Комбинация двух ресурсов — CPU + memory, memory + disk, CPU + disk.

4) Короткий пик — 30–60 секунд повышенной нагрузки. Это проверяет burst-устойчивость и алерты.

5) Длинный тест — 10–30 минут умеренной нагрузки. Это показывает накопительные эффекты: утечки, рост очередей, деградацию кэша, ротацию логов.

На каждом шаге фиксируйте команду и время запуска. Если параллельно работает внешний uptime-мониторинг вроде Statuser, отметьте, были ли реальные недоступности, — это дополнит картину внутренних метрик независимым взглядом снаружи.

Как читать результаты и метрики

Вывод stress-ng обычно заканчивается сводкой. Примерно так:

stress-ng: metrc: [12345] stressor       bogo ops real time  usr time  sys time   bogo ops/s
stress-ng: metrc: [12345] cpu              125432     60.00    239.10     0.45      2090.40

Не воспринимайте bogo ops/s как абсолютную производительность сервера. Это внутренняя метрика конкретного stressor'а — условный счётчик операций, который не заменяет метрики приложения. Её полезно сравнивать:

1) Между одинаковыми серверами — например, два VPS-тарифа или две ноды Kubernetes.

2) До и после изменения конфигурации — ядро, лимиты, governor CPU, параметры диска.

3) Между запусками одного теста — чтобы увидеть нестабильность, throttling, влияние соседней нагрузки.

Гораздо важнее смотреть не только на вывод stress-ng, а на системные и прикладные метрики.

Для CPU:

• user/system/idle/iowait в vmstat, sar;
• load average;
• context switches;
• CPU steal на виртуальных серверах;
• throttling в контейнерах.

Для памяти:

• used/free/available;
• swap in/out;
• page faults;
• OOM events;
• heap и GC приложения.

Для диска:

• await, %util, queue size;
• IOPS и throughput;
• latency базы;
• fsync/checkpoint metrics;
• ошибки файловой системы.

Для веб-сервиса:

• latency p50/p95/p99;
• 5xx;
• timeouts;
• saturation пулов соединений;
• длина очередей;
• health checks.

Хорошая модель наблюдения — смотреть на saturation вместе с latency и errors. Об этом подробно рассказывает подход Golden Signals/RED/USE; для практики можно начать с материала четыре золотых сигнала в мониторинге.

Если после теста сайт «иногда медленный», а не полностью недоступен, среднее время ответа может скрыть проблему. Смотрите p95 и p99: именно хвост latency показывает, как система переживает давление. Для расследования деградаций полезен пошаговый подход из статьи как расследовать деградацию производительности по метрикам.

stress-ng в Docker, systemd и cgroups

stress-ng часто запускают не на хосте, а внутри контейнера. Это удобно для проверки лимитов и поведения оркестратора.

Пример Docker-запуска с ограничением CPU и памяти:

docker run --rm \
  --cpus="1.5" \
  --memory="512m" \
  colinianking/stress-ng \
  --cpu 2 --vm 1 --vm-bytes 400M --timeout 60s --metrics-brief

Образ может отличаться; в корпоративной среде лучше собрать свой минимальный image с нужной версией stress-ng.

Если внутри контейнера запустить больше CPU workers, чем разрешено лимитом, это не даст «магически» больше CPU. Вы увидите throttling: процессы будут готовы работать, но cgroups ограничит фактическое время на CPU. Это как раз полезный тест: приложение должно выдерживать ограничение, а мониторинг должен показывать не только «CPU 100%», но и throttled time.

Для systemd можно ограничить ресурсы временной команды через systemd-run:

sudo systemd-run --scope \
  -p CPUQuota=100% \
  -p MemoryMax=1G \
  stress-ng --cpu 4 --vm 1 --vm-bytes 800M --timeout 2m --metrics-brief

Так вы проверяете нагрузку в рамках заданных лимитов и снижаете риск повлиять на весь сервер. Если хотите глубже разобраться в ограничениях, посмотрите статью как ограничить ресурсы процессов в Linux с помощью cgroups и systemd.

Полезные команды во время контейнерного теста:

docker stats

systemd-cgtop

cat /sys/fs/cgroup/memory.events

На cgroups v2 файл memory.events показывает, были ли события high, max, oom, oom_kill. Это часто информативнее, чем просто смотреть free -h на хосте.

Практический план стресс-теста сервера

Чтобы тест был полезным, относитесь к нему как к мини-эксперименту, а не как к «запустим что-нибудь тяжёлое».

1) Сформулируйте гипотезу — например: «если CPU занят на 80%, API продолжает отвечать быстрее 500 мс на p95» или «при нехватке памяти сервис не падает, а начинает отдавать 503 через graceful degradation».

2) Зафиксируйте окружение — тип сервера, число CPU, RAM, swap, диск, версия ядра, контейнерные лимиты, версия приложения.

3) Включите наблюдение — системные метрики, метрики приложения, логи, внешний мониторинг доступности, алерты.

4) Запустите короткий тест — 30–60 секунд с умеренной нагрузкой.

stress-ng --cpu 2 --vm 1 --vm-bytes 512M --timeout 60s --metrics-brief

5) Увеличивайте нагрузку ступенями — не переходите сразу от лёгкого теста к полному насыщению. После каждого шага дайте системе восстановиться.

6) Проверяйте пользовательский эффект — запросы к API, открытие сайта, фоновые задачи, очереди, админки, cron. Системные метрики без прикладного контекста легко неправильно интерпретировать.

7) Завершите тест и проверьте хвост — некоторые проблемы проявляются после нагрузки: накопленные очереди, прогрев кэша, повторные попытки, ротация логов, переподключения к базе.

8) Запишите выводы — какие пороги опасны, какие алерты сработали, что нужно изменить: лимиты, пул соединений, autoscaling, swap, диски, настройки сервиса.

Если во время теста сайт ушёл в 502/503/504, не ограничивайтесь выводом «сервер не выдержал». Надо понять, что именно закончилось: CPU, память, воркеры, соединения к базе, очередь accept, файловые дескрипторы, I/O. stress-ng создаёт условия, а расследование всё равно идёт по метрикам и логам.

Частые ошибки

1) Запуск без --timeout — классика. Команда уходит в фон, SSH начинает тормозить, остановить тест сложно. Всегда задавайте время.

2) Тестирование продакшена как staging — стресс-тест на рабочей машине должен быть мягким, коротким и согласованным. Если цель — найти предел, делайте это на отдельном стенде.

3) Ориентация только на CPU — многие сбои вызваны не процессором, а памятью, диском, сетью, лимитами процессов или файловых дескрипторов.

4) Игнорирование виртуализации — на VPS возможен CPU steal, noisy neighbor и лимиты провайдера. Два одинаковых запуска могут отличаться не из-за вашего приложения.

5) Сравнение разных stressors по bogo ops — нельзя напрямую сравнивать cpu и matrix или hdd и io. Сравнивайте одинаковые команды.

6) Отсутствие baseline — если не знаете, как сервер выглядит в норме, трудно понять, насколько тест ухудшил ситуацию.

7) Запуск дискового теста на корневом разделе — можно забить /, сломать запись логов и работу сервисов. Используйте --temp-path и контролируйте df -h.

stress-ng — мощный «генератор плохих условий». Он не заменяет нагрузочное тестирование API, профилирование и мониторинг, но отлично помогает проверить устойчивость сервера к насыщению ресурсов. Начинайте с коротких тестов, повышайте нагрузку ступенями и всегда смотрите не только на вывод утилиты, но и на пользовательский эффект.

FAQ

Можно ли запускать stress-ng на продакшене?

Можно, но осторожно: короткими тестами, с --timeout, умеренной нагрузкой и включённым мониторингом. Поиск предела лучше проводить на staging.

stress-ng показывает реальную производительность сервера?

Не совсем. Он показывает поведение системы под искусственной нагрузкой. bogo ops полезны для сравнения одинаковых тестов, но не являются универсальным бенчмарком.

Чем stress-ng отличается от k6, wrk и ab?

stress-ng нагружает ресурсы сервера локально: CPU, память, диск, процессы. k6, wrk и ab генерируют HTTP-нагрузку на приложение.

Как безопаснее всего начать?

Запустите CPU-тест на 30–60 секунд с небольшим числом workers: stress-ng --cpu 1 --timeout 60s --metrics-brief. Затем добавляйте память и диск только после настройки наблюдения.