How can I produce high CPU load on a Linux server?

I’m currently in the process of debugging a Cacti installation and want to create CPU load to debug my CPU utilization graphs.

I tried to simply run cat /dev/zero > /dev/null, which works great but only utilizes 1 core:

Is there a better method of testing/maxing-out system resources under load?

Related: How can I produce high CPU load on Windows?

Solution 1:

Try stress It's pretty much an equivalent of the Windows consume.exe:

oliver$ ./stress --cpu 3
stress: info: [18472] dispatching hogs: 3 cpu, 0 io, 0 vm, 0 hdd

Solution 2:

No need to install any extra package, your good old shell is able to do it alone.

This one-liner will load your four cores¹ at 100%:

for i in 1 2 3 4; do while : ; do : ; done & done

How it works is quite simple, it starts four endless loops. Each of them is repeating the null instruction (:). Each loop is able to load a CPU core at 100%.

If you use bash, ksh93 and other shells supporting ranges, (i.e. not dash or older ksh), you can use this non portable syntax:

for i in {1..4}; do ...

Replace 4 with the number of CPUs you'd like to load if different from 4.

Assuming you had no background job already running when you launched one of these loops, you can stop the load generation with that command:

for i in 1 2 3 4; do kill %$i; done

Answering @underscore_d's comment, here is an enhanced version that simplify a lot stopping the load and that also allow specifying a timeout (default 60 seconds.) A Control-C will kill all the runaway loops too. This shell function works at least under bash and ksh.

# Usage: lc [number_of_cpus_to_load [number_of_seconds] ]
lc() {
  (
    pids=""
    cpus=${1:-1}
    seconds=${2:-60}
    echo loading $cpus CPUs for $seconds seconds
    trap 'for p in $pids; do kill $p; done' 0
    for ((i=0;i<cpus;i++)); do while : ; do : ; done & pids="$pids $!"; done
    sleep $seconds
  )
}

¹_{Note that with CPUs supporting more than one thread per core (Hyper-threading), the OS will dispatch the load to all virtual CPUs. In that case, the load behavior is implementation dependent (each thread might be reported as 100% busy or not).}.

Solution 3:

One alternative way would be

openssl speed -multi $(grep -ci processor /proc/cpuinfo)

or (if nproc is present)

openssl speed -multi $(nproc --all)

OpenSSL is almost always present on nowadays distros, so no extra packages needed.