stress-ng(1)

stress-ng - a tool to load and stress a computer system

[OPTION [ARG]] ...

stress-ng will stress test a computer system in various selectable ways. It was designed to exercise various physical subsystems of a computer as well as the various operating system kernel interfaces. stress-ng also has a wide range of CPU specific stress tests that exercise floating point, integer, bit manipulation and control flow.

stress-ng was originally intended to make a machine work hard and trip hardware issues such as thermal overruns as well as operating system bugs that only occur when a system is being thrashed hard. Use stress-ng with caution as some of the tests can make a system run hot on poorly designed hardware and also can cause excessive system thrashing which may be difficult to stop.

stress-ng can also measure test throughput rates; this can be useful to observe performance changes across different operating system releases or types of hardware. However, it has never been intended to be used as a precise benchmark test suite, so do NOT use it in this manner.

Running stress-ng with root privileges will adjust out of memory settings on Linux systems to make the stressors unkillable in low memory situations, so use this judiciously. With the appropriate privilege, stress-ng can allow the ionice class and ionice levels to be adjusted, again, this should be used with care.

One can specify the number of processes to invoke per type of stress test; specifying a zero value will select the number of processors available as defined by sysconf(_SC_NPROCESSORS_CONF), if that can't be determined then the number of online CPUs is used. If the value is less than zero then the number of online CPUs is used.

this option will force all running stressors to abort (terminate) if any other stressor terminates prematurely because of a failure.

enables more file, cache and memory aggressive options. This may slow tests down, increase latencies and reduce the number of bogo ops as well as changing the balance of user time vs system time used depending on the type of stressor being used.

start N instances of all stressors in parallel. If N is less than zero, then the number of CPUs online is used for the number of instances. If N is zero, then the number of configured CPUs in the system is used.

wait N microseconds between the start of each stress worker process. This allows one to ramp up the stress tests over time.

specify the class of stressors to run. Stressors are classified into one or more of the following classes: cpu, cpu-cache, device, gpu, io, interrupt, filesystem, memory, network, os, pipe, scheduler and vm. Some stressors fall into just one class. For example the 'get' stressor is just in the 'os' class. Other stressors fall into more than one class, for example, the 'lsearch' stressor falls into the 'cpu', 'cpu-cache' and 'memory' classes as it exercises all these three. Selecting a specific class will run all the stressors that fall into that class only when run with the --sequential option.

Specifying a name followed by a question mark (for example --class vm?) will print out all the stressors in that specific class.

parse options, but do not run stress tests. A no-op.

enable kernel function call tracing (Linux only). This will use the kernel debugfs ftrace mechanism to record all the kernel functions used on the system while stress-ng is running. This is only as accurate as the kernel ftrace output, so there may be some variability on the data reported.

show help.

alter kernel controls to try and maximize the CPU. This requires root privilege to alter various /sys interface controls. Currently this only works for Intel P-State enabled x86 systems on Linux.

specify ionice class (only on Linux). Can be idle (default), besteffort, be, realtime, rt.

specify ionice level (only on Linux). For idle, 0 is the only possible option. For besteffort or realtime values 0 (highest priority) to 7 (lowest priority). See ionice(1) for more details.

every S seconds show I/O statistics on the device that stores the stress-ng temporary files. This is either the device of the current working directory or the --temp-path specified path. Currently a Linux only option. The fields output are:

expand; lB lB lB l l s. Column Heading Explanation T{ Inflight T} T{ number of I/O requests that have been issued to the device driver but have not yet completed T} T{ Rd K/s T} T{ read rate in 1024 bytes per second T} T{ Wr K/s T} T{ write rate in 1024 bytes per second T} T{ Dscd K/s T} T{ discard rate in 1024 bytes per second T} T{ Rd/s T} T{ reads per second T} T{ Wr/s T} T{ writes per second T} T{ Dscd/s T} T{ discards per second T}

run stressors using a jobfile. The jobfile is essentially a file containing stress-ng options (without the leading --) with one option per line. Lines may have comments with comment text proceeded by the # character. A simple example is as follows:

run sequential # run stressors sequentially verbose # verbose output metrics-brief # show metrics at end of run timeout 60s # stop each stressor after 60 seconds # # vm stressor options: # vm 2 # 2 vm stressors vm-bytes 128M # 128MB available memory vm-keep # keep vm mapping vm-populate # populate memory # # memcpy stressor options: # memcpy 5 # 5 memcpy stressors

The job file introduces the run command that specifies how to run the stressors:

run sequential - run stressors sequentially

run parallel - run stressors together in parallel

Note that 'run parallel' is the default.

do not remove files and directories created by the stressors. This can be useful for debugging purposes. Not generally recommended as it can fill up a file system.

by default, stress-ng will attempt to change the name of the stress processes according to their functionality; this option disables this and keeps the process names to be the name of the parent process, that is, stress-ng.

check the kernel log for kernel error and warning messages and report these as soon as they are detected. Linux only and requires root capability to read the kernel log.

by default stress-ng will report the name of the program, the message type and the process id as a prefix to all output. The --log-brief option will output messages without these fields to produce a less verbose output.

write messages to the specified log file.

log messages use a lock to avoid intermingling of blocks of stressor messages, however this may cause contention when emitting a high rate of logging messages in verbose mode. This option disables log message locking.

overrides the default stressor settings and instead sets these to the maximum settings allowed. These defaults can always be overridden by the per stressor settings options if required.

set the maximum limit on file descriptors (value or a % of system allowed maximum). By default, stress-ng can use all the available file descriptors; this option sets the limit in the range from 10 up to the maximum limit of RLIMIT_NOFILE. One can use a % setting too, e.g. 50% is half the maximum allowed file descriptors. Note that stress-ng will use about 5 of the available file descriptors so take this into consideration when using this setting.

set strict NUMA memory allocation based on the list of NUMA nodes provided; page allocations will come from the node with sufficient free memory closest to the specified node(s) where the allocation takes place. This uses the Linux set_mempolicy(2) call using the MPOL_BIND mode. The NUMA nodes to be used are specified by a comma separated list of node (0 to N-1). One can specify a range of NUMA nodes using '-', for example: --mbind 0,2-3,6,7-11

output number of bogo operations in total performed by the stress processes. Note that these are

and

have not been designed to be used for benchmarking whatsoever. Some stressors have additional metrics that are more useful than bogo-ops, and these are generally more useful for observing how a system behaves when under various kinds of load.

The following columns of information are output:

expand; lB lB lB l l s. Column Heading Explanation T{ bogo ops T} T{ number of iterations of the stressor during the run. This is metric of how much overall "work" has been achieved in bogo operations.

Do not use this as a reliable measure of throughput for benchmarking. T} T{ real time (secs) T} T{ average wall clock duration (in seconds) of the stressor. This is the total wall clock time of all the instances of that particular stressor divided by the number of these stressors being run. T} T{ usr time (secs) T} T{ total user time (in seconds) consumed running all the instances of the stressor. T} T{ sys time (secs) T} T{ total system time (in seconds) consumed running all the instances of the stressor. T} T{ bogo ops/s (real time) T} T{ total bogo operations per second based on wall clock run time. The wall clock time reflects the apparent run time. The more processors one has on a system the more the work load can be distributed onto these and hence the wall clock time will reduce and the bogo ops rate will increase. This is essentially the "apparent" bogo ops rate of the system. T} T{ bogo ops/s (usr+sys time) T} T{ total bogo operations per second based on cumulative user and system time. This is the real bogo ops rate of the system taking into consideration the actual time execution time of the stressor across all the processors. Generally this will decrease as one adds more concurrent stressors due to contention on cache, memory, execution units, buses and I/O devices. T} T{ CPU used per instance (%) T} T{ total percentage of CPU used divided by number of stressor instances. 100% is 1 full CPU. Some stressors run multiple threads so it is possible to have a figure greater than 100%. T}

show shorter list of stressor metrics (no CPU used per instance).

overrides the default stressor settings and instead sets these to the minimum settings allowed. These defaults can always be overridden by the per stressor settings options if required.

from version 0.02.26 stress-ng automatically calls madvise(2) with random advise options before each mmap and munmap to stress the vm subsystem a little harder. The --no-advise option turns this default off.

disable any form of out-of-memory score adjustments, keep the system defaults. Normally stress-ng will adjust the out-of-memory scores on stressors to try to create more memory pressure. This option disables the adjustments.

Do not seed the stress-ng pseudo-random number generator with a quasi random start seed, but instead seed it with constant values. This forces tests to run each time using the same start conditions which can be useful when one requires reproducible stress tests.

Attempt to avoid out-of-memory conditions that can lead to the Out-of-Memory (OOM) killer terminating stressors. This checks for low memory scenarios and swapping before making memory allocations and hence adds some overhead to the stressors and will slow down stressor allocation speeds.

Specify a low memory threshold to avoid making any further memory allocations. The parameter can be specified as an absolute number of bytes (e.g. 2M for 2MB) or a percentage of the current free memory, e.g. 5% (the default is 2.5%). This option implicitly enables --oom-avoid. The option allows the system to have enough free memory to try to avoid the out-of-memory killer terminating processes.

Do not respawn a stressor if it gets killed by the Out-of-Memory (OOM) killer. The default behaviour is to restart a new instance of a stressor if the kernel OOM killer terminates the process. This option disables this default behaviour.

touch allocated pages that are not in core, forcing them to be paged back in. This is a useful option to force all the allocated pages to be paged in when using the bigheap, mmap and vm stressors. It will severely degrade performance when the memory in the system is less than the allocated buffer sizes. This uses mincore(2) to determine the pages that are not in core and hence need touching to page them back in.

enable stressors that are known to hang systems. Some stressors can rapidly consume resources that may hang a system, or perform actions that can lock a system up or cause it to reboot. These stressors are not enabled by default, this option enables them, but you probably don't want to do this. You have been warned. This option applies to the stressors: bad-ioctl, bind-mount, cpu-online, mlockmany, oom-pipe, smi, sysinval and watchdog.

measure processor and system activity using perf events. Linux only and caveat emptor, according to perf_event_open(2): "Always double-check your results! Various generalized events have had wrong values.". Note that with Linux 4.7 one needs to have CAP_SYS_ADMIN capabilities for this option to work, or adjust /proc/sys/kernel/perf_event_paranoid to below 2 to use this without CAP_SYS_ADMIN.

do not show any output.

start N random stress workers. If N is 0, then the number of configured processors is used for N.

select the named scheduler (only on Linux). To see the list of available schedulers use: stress-ng --sched which

select the scheduler priority level (only on Linux). If the scheduler does not support this then the default priority level of 0 is chosen.

select the period parameter for deadline scheduler (only on Linux). Default value is 0 (in nanoseconds).

select the runtime parameter for deadline scheduler (only on Linux). Default value is 99999 (in nanoseconds).

select the deadline parameter for deadline scheduler (only on Linux). Default value is 100000 (in nanoseconds).

use cpu bandwidth reclaim feature for deadline scheduler (only on Linux).

set the random number generate seed with a 64 bit value. Allows stressors to use the same random number generator sequences on each invocation.

sequentially run all the stressors one by one for a default of 60 seconds. The number of instances of each of the individual stressors to be started is N. If N is less than zero, then the number of CPUs online is used for the number of instances. If N is zero, then the number of CPUs in the system is used. Use the --timeout option to specify the duration to run each stressor.

silence messages that report that a stressor has been skipped because it requires features not supported by the system, such as unimplemented system calls, missing resources or processor specific features.

scan the block devices for changes S.M.A.R.T. statistics (Linux only). This requires root privileges to read the Self-Monitoring, Analysis and Reporting Technology data from all block devies and will report any changes in the statistics. One caveat is that device manufacturers provide different sets of data, the exact meaning of the data can be vague and the data may be inaccurate.

use scientific notation (e.g. 2.412e+01) for metrics.

all output goes to stdout. By default all output goes to stderr (which is a historical oversight that will cause breakage to users if it is now changed). This option allows the output to be written to stdout.

output the names of the available stressors.

log output (except for verbose -v messages) to the syslog.

set CPU affinity based on the list of CPUs provided; stress-ng is bound to just use these CPUs (Linux only). The CPUs to be used are specified by a comma separated list of CPU (0 to N-1). One can specify a range of CPUs using '-', for example: --taskset 0,2-3,6,7-11

specify a path for stress-ng temporary directories and temporary files; the default path is the current working directory. This path must have read and write access for the stress-ng stress processes.

every S seconds show CPU and thermal load statistics. This option shows average CPU frequency in GHz (average of online-CPUs), the minimum CPU frequency, the maximum CPU frequency, load averages (1 minute, 5 minute and 15 minutes) and available thermal zone temperatures in degrees Centigrade.

This can only be used when running on Linux and with root privilege. This option starts a background thrasher process that works through all the processes on a system and tries to page as many pages in the processes as possible. It also periodically drops the page cache, frees reclaimable slab objects and pagecache. This will cause considerable amount of thrashing of swap on an over-committed system.

run each stress test for at least T seconds. One can also specify the units of time in seconds, minutes, hours, days or years with the suffix s, m, h, d or y. Each stressor will be sent a SIGALRM signal at the timeout time, however if the stress test is swapped out, in a non-interritable system call or performing clean up (such as removing hundreds of test file) it may take a while to finally terminate. A 0 timeout will run stress-ng for ever with no timeout.

add a timestamp in hours, minutes, seconds and hundredths of a second to the log output.

adjust the per process timer slack to N nanoseconds (Linux only). Increasing the timer slack allows the kernel to coalesce timer events by adding some fuzziness to timer expiration times and hence reduce wakeups. Conversely, decreasing the timer slack will increase wakeups. A value of 0 for the timer-slack will set the system default of 50,000 nanoseconds.

show the cumulative user and system times of all the child processes at the end of the stress run. The percentage of utilisation of available CPU time is also calculated from the number of on-line CPUs in the system.

collect temperatures from the available thermal zones on the machine (Linux only). Some devices may have one or more thermal zones, where as others may have none.

show all debug, warnings and normal information output.

verify results when a test is run. This is not available on all tests. This will sanity check the computations or memory contents from a test run and report to stderr any unexpected failures.

print the names of stressors that can be verified with the --verify option.

show version of stress-ng, version of toolchain used to build stress-ng and system information.

every S seconds show statistics about processes, memory, paging, block I/O, interrupts, context switches, disks and cpu activity. The output is similar that to the output from the vmstat(8) utility. Currently a Linux only option.

specify a list of one or more stressors to exclude (that is, do not run them). This is useful to exclude specific stressors when one selects many stressors to run using the --class option, --sequential, --all and --random options. Example, run the cpu class stressors concurrently and exclude the numa and search stressors:

stress-ng --class cpu --all 1 -x numa,bsearch,hsearch,lsearch

output gathered statistics to a YAML formatted file named 'filename'.

start N workers that work through various settings of file mode bits (read, write, execute) for the file owner and checks if the user permissions of the file using access(2) and faccessat(2) are sane.

stop access workers after N bogo access sanity checks.

start N workers that run 16 processes that rapidly change CPU affinity (only on Linux). Rapidly switching CPU affinity can contribute to poor cache behaviour and high context switch rate.

stop affinity workers after N bogo affinity operations.

delay for N nanoseconds before changing affinity to the next CPU. The delay will spin on CPU scheduling yield operations for N nanoseconds before the process is moved to another CPU. The default is 0 nanosconds.

pin all the 16 per stressor processes to a CPU. All 16 processes follow the CPU chosen by the main parent stressor, forcing heavy per CPU loading.

switch CPU affinity randomly rather than the default of sequentially.

sleep for N nanoseconds before changing affinity to the next CPU.

start N workers that exercise the AF_ALG socket domain by hashing and encrypting various sized random messages. This exercises the available hashes, ciphers, rng and aead crypto engines in the Linux kernel.

stop af-alg workers after N AF_ALG messages are hashed.

dump the internal list representing cryptographic algorithms parsed from the /proc/crypto file to standard output (stdout).

start N workers that issue multiple small asynchronous I/O writes and reads on a relatively small temporary file using the POSIX aio interface. This will just hit the file system cache and soak up a lot of user and kernel time in issuing and handling I/O requests. By default, each worker process will handle 16 concurrent I/O requests.

stop POSIX asynchronous I/O workers after N bogo asynchronous I/O requests.

specify the number of POSIX asynchronous I/O requests each worker should issue, the default is 16; 1 to 4096 are allowed.