Skip to content
Latchkey

stress-ng: Usage, Options & Common CI Errors

stress-ng imposes configurable load on CPU, memory, I/O, and more.

stress-ng deliberately stresses subsystems to test stability, thermals, or autoscaling. In CI you almost always pair it with --timeout so it stops, and you must respect the runner memory ceiling.

What it does

stress-ng spins up workers ("stressors") that load CPU, memory (--vm), disk (--hdd/--io), and dozens of other subsystems, optionally validating results with --verify. --timeout bounds the run and --metrics summarizes throughput.

Common usage

Terminal
stress-ng --cpu 4 --timeout 60s
stress-ng --cpu 2 --vm 2 --vm-bytes 512M --timeout 30s
stress-ng --cpu 0 --timeout 60s                # 0 = one per online CPU
stress-ng --io 4 --hdd 2 --timeout 45s --metrics-brief
stress-ng --matrix 0 --timeout 1m --verify

Options

FlagWhat it does
--cpu <N>N CPU stressor workers (0 = one per CPU)
--vm <N> --vm-bytes <sz>N memory stressors using sz each
--timeout <t>Stop after this long (e.g. 60s, 5m)
--metrics[-brief]Report bogo-ops throughput
--verifyValidate computations (catches faulty hardware)

Common errors in CI

Forgetting --timeout means stress-ng runs forever and the job hangs - always bound it. "--vm-bytes" beyond the runner RAM triggers the kernel OOM killer: workers die with "stress-ng: ... worker ... got killed (signal 9 SIGKILL)" / "out of memory" and the exit is non-zero; size --vm-bytes below available memory. On a container with a CPU quota, --cpu 0 may over-subscribe and skew metrics. "command not found" - it is the stress-ng package (the older "stress" tool is a different, simpler binary).

Related guides

Run this faster and cheaper on Latchkey managed runners. Start free →