To increase CPU usage for testing in an AWS Ubuntu instance, we can generate artificial load on the CPU using tools like stress, stress-ng, or custom scripts. Here's how you can achieve this:
1. Using stress
stress is a simple workload generator for Linux systems.
Install stress:
sudo apt update
sudo apt install stress
Generate CPU Load:
Run the following command to create CPU stress:
stress --cpu 4 --timeout 60
-
--cpu 4: Number of CPU cores to stress (adjust based on your instance's available cores). -
--timeout 60: Duration in seconds for the stress test.
2. Using stress-ng
stress-ng is more advanced and flexible than stress.
Install stress-ng:
sudo apt update
sudo apt install stress-ng
Generate CPU Load:
Run this command to stress all CPUs:
stress-ng --cpu 4 --cpu-load 80 --timeout 60s
-
--cpu 4: Number of CPU stressors to run (one per core). -
--cpu-load 80: Set each CPU to run at 80% utilization. -
--timeout 60s: Run for 60 seconds.
3. Using a Custom Script
You can also use a simple shell script to load the CPU.
Bash Script:
#!/bin/bash
while :; do :; done
Run the Script:
Save the script as cpu_load.sh and execute it:
chmod +x cpu_load.sh
./cpu_load.sh &
This will create a full load on a single core. To create additional load, run multiple instances of the script in the background.
4. Using yes Command
You can use the yes command to generate CPU load.
Run the Command:
yes > /dev/null &
Run this multiple times to stress more cores. Stop the process using kill or pkill yes.
5. Monitoring CPU Usage
To monitor CPU usage during the test, use:
top
or
htop
(Install htop with sudo apt install htop).
6. Clean Up
After testing, terminate the stress processes:
- For
stressorstress-ng, they stop automatically after the timeout. - For background scripts or
yes, stop them manually:
killall stress
killall stress-ng
killall yes
pkill -f cpu_load.sh
Top comments (2)
I don't see how this helps with performance testing. All it does is add load to the CPU.
It's not realistic of how your website/application/crons etc would be causing load based on user connections and db queries and such.
This is like "Look ma, i'm gonna spin the wheel on my bike to see how fast it can spin" with my bike upside down. Nevermind what happens when i'm on the bike.
Thank you for your insightful comment! You're absolutely right that simulating artificial CPU load as described in the blog primarily serves as a way to test the server's basic processing limits, thermal performance, or behavior under continuous CPU-intensive tasks. It doesn't reflect the complexities of real-world application performance, such as user interactions, database queries, or specific workloads.
For realistic performance testing, tools like Apache JMeter, Locust, or k6 can simulate user traffic, while profiling tools like New Relic or Datadog provide deeper insights into bottlenecks caused by application code or database operations.
This blog focuses on creating a baseline understanding of how CPU behaves under stress, which can sometimes be useful for hardware benchmarking or basic server capacity evaluation. However, you're absolutely right that more context-specific load testing is critical for assessing how an application performs under real-world scenarios.
Thank you again for highlighting this point—it adds valuable nuance to the conversation, and I may explore this topic in a follow-up blog post! 😊