X-STR
stress-ng
System stress-testing tool that loads CPU, memory, I/O, and network resources to test availability under an authorized DoS test.
OVERVIEW
stress-ng (github.com/ColinIanKing/stress-ng) is a Linux system stress-testing tool with well over a hundred selectable stressors covering CPU, memory, disk I/O, network sockets, filesystem operations, and more, each with tunable worker counts and a time or iteration limit. It was built for kernel and hardware reliability testing, not offense, but the same load generators are exactly what a scoped availability/DoS test needs to demonstrate that a service degrades or falls over under resource pressure.
In an engagement context it's used to validate a specific, pre-agreed hypothesis — this endpoint has no rate limiting, this service has no memory ceiling, this autoscaling policy doesn't trigger in time — rather than to run indiscriminately; the output (metrics, bogo-ops/sec, timing) documents exactly how much load was applied and for how long, which becomes the evidence in the report.
USE CASES
Practical use cases
- 01
Demonstrating that an endpoint or service lacks rate limiting by driving CPU/socket load until it degrades.
- 02
Testing whether monitoring and alerting actually fire when a resource-exhaustion condition occurs.
- 03
Validating autoscaling or failover behavior under a controlled, time-boxed load spike.
- 04
Reproducing a client-reported availability issue under a repeatable, measured stress profile.
QUICK START
Only inside an explicitly authorized, scheduled DoS/availability-testing window — to see how a target system or its monitoring/alerting responds under real resource pressure.
- Get explicit written authorization for a DoS/availability test, including the exact scope, target, and maintenance window.
- Agree a rollback/abort plan and a point of contact on the client side before starting.
- Install stress-ng from the distro package manager or build from source.
- Run a time-boxed stressor against the agreed resource (CPU, memory, sockets) at the agreed intensity.
- Monitor the target's actual behavior (latency, errors, alerts) throughout, and stop immediately if it exceeds the agreed impact.
stress-ng --cpu 4 --vm 2 --vm-bytes 1G --timeout 60s --metrics-briefBEFORE YOU RUN IT
What to check before running it
This is DoS-adjacent testing: never run it against a target without explicit written authorization naming stress-ng specifically, an agreed maintenance window, and a rollback plan — an unscoped run can take down production.
Always start at low intensity and a short timeout, then step up only as agreed; resource exhaustion on shared infrastructure can affect tenants or services outside the intended scope.
Keep a monitor on the target throughout the run and stop immediately on any sign of impact beyond what was authorized — the goal is evidence, not an outage.