As a System Administrator, you may want to examine and monitor the status of your Linux systems when they are under stress of high load. This can be a good way for System Administrators and Programmers to:

fine tune activities on a system. monitor operating system kernel interfaces. test your Linux hardware components such as CPU, memory, disk devices and many others to observe their performance under stress. measure different power consuming loads on a system.

In this guide, we shall look at two important tools, stress and stress-ng for stress testing under your Linux systems.

1. stress – is a workload generator tool designed to subject your system to a configurable measure of CPU, memory, I/O and disk stress.

2. stress-ng – is an updated version of the stress workload generator tool which tests your system for following features:

CPU compute drive stress I/O syncs Pipe I/O cache thrashing VM stress socket stressing process creation and termination context switching properties

Though these tools are good for examining your system, they should not just be used by any system user.

Important: It is highly recommended that you use these tools with root user privileges, because they can stress your Linux machine so fast and to avoid certain system errors on poorly designed hardware.

How to Install ‘stress’ Tool in Linux

To install stress tool on Debian and its derivatives such Ubuntu and Mint, run the following command.

$ sudo apt-get install stress

To install stress on a RHEL/CentOS and Fedora Linux, you need to turn on EPEL repository and then type the following yum command to install the same:

# yum install stress

The general syntax for using stress is:

$ sudo stress option argument

Some options that you can use with stress.

To spawn N workers spinning on sqrt() function, use the –cpu N option as follows. To spawn N workers spinning on sync() function, use the –io N option as follows. To spawn N workers spinning on malloc()/free() functions, use the –vm N option. To allocate memory per vm worker, use the –vm-bytes N option. Instead of freeing and reallocating memory resources, you can redirty memory by using the –vm-keep option. Set sleep to N seconds before freeing memory by using the –vm-hang N option. To spawn N workers spinning on write()/unlink() functions, use the –hdd N option. You can set a timeout after N seconds by using the –timeout N option. Set a wait factor of N microseconds before any work starts by using the –backoff N option as follows. To show more detailed information when running stress, use the -v option. Use –help to view help for using stress or view the manpage.

How Do I use stress on Linux systems?

1. To examine effect of the command every time you run it, first run the uptime command and note down the load average.

Next, run the stress command to spawn 8 workers spinning on sqrt() with a timeout of 20 seconds. After running stress, again run the uptime command and compare the load average.

Sample Output

[email protected] ~ $ uptime 17:20:00 up 7:51, 2 users, load average: 1.91, 2.16, 1.93 [<-- Watch Load Average] [email protected] ~ $ sudo stress --cpu 8 --timeout 20 stress: info: [17246] dispatching hogs: 8 cpu, 0 io, 0 vm, 0 hdd stress: info: [17246] successful run completed in 21s [email protected] ~ $ uptime 17:20:24 up 7:51, 2 users, load average: 5.14, 2.88, 2.17 [<-- Watch Load Average]

2. To spawn 8 workers spinning on sqrt() with a timeout of 30 seconds, showing detailed information about the operation, run this command:

Sample Output

[email protected] ~ $ uptime 17:27:25 up 7:58, 2 users, load average: 1.40, 1.90, 1.98 [<-- Watch Load Average] [email protected] ~ $ sudo stress --cpu 8 -v --timeout 30s stress: info: [17353] dispatching hogs: 8 cpu, 0 io, 0 vm, 0 hdd stress: dbug: [17353] using backoff sleep of 24000us stress: dbug: [17353] setting timeout to 30s stress: dbug: [17353] --> hogcpu worker 8 [17354] forked stress: dbug: [17353] using backoff sleep of 21000us stress: dbug: [17353] setting timeout to 30s stress: dbug: [17353] --> hogcpu worker 7 [17355] forked stress: dbug: [17353] using backoff sleep of 18000us stress: dbug: [17353] setting timeout to 30s stress: dbug: [17353] --> hogcpu worker 6 [17356] forked stress: dbug: [17353] using backoff sleep of 15000us stress: dbug: [17353] setting timeout to 30s stress: dbug: [17353] --> hogcpu worker 5 [17357] forked stress: dbug: [17353] using backoff sleep of 12000us stress: dbug: [17353] setting timeout to 30s stress: dbug: [17353] --> hogcpu worker 4 [17358] forked stress: dbug: [17353] using backoff sleep of 9000us stress: dbug: [17353] setting timeout to 30s stress: dbug: [17353] --> hogcpu worker 3 [17359] forked stress: dbug: [17353] using backoff sleep of 6000us stress: dbug: [17353] setting timeout to 30s stress: dbug: [17353] --> hogcpu worker 2 [17360] forked stress: dbug: [17353] using backoff sleep of 3000us stress: dbug: [17353] setting timeout to 30s stress: dbug: [17353] --> hogcpu worker 1 [17361] forked stress: dbug: [17353] [email protected] ~ $ uptime 17:27:59 up 7:59, 2 users, load average: 5.41, 2.82, 2.28 [<-- Watch Load Average]

3. To spwan one worker of malloc() and free() functions with a timeout of 60 seconds, run the following command.

Sample Output

[email protected] ~ $ uptime 17:34:07 up 8:05, 2 users, load average: 1.54, 2.04, 2.11 [<-- Watch Load Average] [email protected] ~ $ sudo stress --vm 1 --timeout 60s stress: info: [17420] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd stress: info: [17420] successful run completed in 60s [email protected] ~ $ uptime 17:35:20 up 8:06, 2 users, load average: 2.45, 2.24, 2.17 [<-- Watch Load Average]

4. To spwan 4 workers spinning on sqrt(), 2 workers spwaning on sync(), 2 workers on malloc()/free(), with a time out of 20 seconds and allocate a memory of 256MB per vm worker, run this command below.

Sample Output

[email protected] ~ $ uptime 17:40:33 up 8:12, 2 users, load average: 1.68, 1.84, 2.02 [<-- Watch Load Average] [email protected] ~ $ sudo stress --cpu 4 --io 3 --vm 2 --vm-bytes 256M --timeout 20s stress: info: [17501] dispatching hogs: 4 cpu, 3 io, 2 vm, 0 hdd stress: info: [17501] successful run completed in 20s [email protected] ~ $ uptime 17:40:58 up 8:12, 2 users, load average: 4.63, 2.54, 2.24 [<-- Watch Load Average]