If you’ve ever been asked, “The CPU is only 20%, but the Load Average is 15. What’s happening?”—this article is for you.
One of the most misunderstood concepts in Linux is Load Average. Many engineers assume that a high load average automatically means high CPU utilization. In reality, that’s not always true.
As a Linux Administrator or DevOps Engineer, understanding the relationship between Load Average, CPU Utilization, and Disk I/O is essential—not only for interviews but also for troubleshooting production incidents.
Let’s break it down with real-world examples.
What is Load Average?
Load Average represents the average number of processes that are either:
- Running on the CPU
- Waiting to get CPU time
- Waiting in an uninterruptible state (usually Disk I/O)
Unlike CPU utilization, Load Average measures system demand, not how busy the CPU is.
Imagine a supermarket:
- The cashier is the CPU.
- Customers are processes.
If five customers are waiting in line, even if the cashier is working normally, the queue (load) is high.
Linux works in a similar way.
Understanding the Three Numbers
When you run:
uptime
You may see something like:
21:35:17 up 12 days, 4:18, 2 users, load average: 0.82, 1.45, 2.31
These numbers represent:
- 0.82 → Average load over the last 1 minute
- 1.45 → Average load over the last 5 minutes
- 2.31 → Average load over the last 15 minutes
These values help identify whether the system load is increasing or decreasing over time.
How to Interpret Load Average
The interpretation depends on the number of CPU cores.
For a server with:
- 1 CPU Core
- Load = 1 → Normal
- Load = 2 → One process waiting
- Load = 5 → Four processes waiting
For a server with:
- 8 CPU Cores
- Load = 8 → Fully utilized
- Load = 12 → Four processes waiting
- Load = 20 → Heavy contention
A common rule of thumb is:
💡 Tip: Always compare the Load Average with the number of logical CPU cores. For example, a Load Average of 8 on an 8-core server is generally acceptable, while a Load Average of 16 indicates that processes are waiting for CPU or I/O resources.
You can check the number of CPU cores using:
nproc
8
or
lscpu
The Most Common Interview Question
Question:
CPU utilization is only 20%, but the Load Average is 15. How is that possible?
Many candidates answer:
“The CPU is overloaded.”
That’s incorrect.
A high Load Average with low CPU utilization often indicates that processes are waiting for another resource—most commonly Disk I/O.
Understanding Disk I/O
Every application reads from and writes to storage.
Examples include:
- MySQL reading database pages
- Apache serving images
- Nginx writing access logs
- Backup jobs reading large files
- File uploads
- Log rotation
If the storage becomes slow, processes cannot continue until the read or write operation completes.
These processes enter the D (Uninterruptible Sleep) state.
Processes in the D state contribute to the Load Average.
What is I/O Wait (wa)?
Run:
top
or
vmstat 1
You’ll notice CPU statistics such as:
us sy id wa
Where:
- us = User CPU time
- sy = System CPU time
- id = Idle CPU
- wa = CPU waiting for Disk I/O
A high wa value usually indicates that storage performance is limiting the system.
Example:
CPU Usage
User : 10%
System : 8%
Idle : 22%
IO Wait : 60%
This does not mean the CPU is busy.
It means the CPU is idle because processes are waiting for the disk.
Real Production Example
Suppose your monitoring shows:
CPU Usage : 18%
Load Average : 25
IO Wait : 55%
Users report that the website is slow.
At first glance, someone might say:
“CPU is fine.”
However, the real issue is likely storage performance.
Possible causes include:
- Slow EBS volume
- Heavy database writes
- Large backup process
- RAID rebuild
- NFS latency
- High disk queue depth
This is why checking only CPU utilization is never enough.
Commands Every Linux Engineer Should Know
Check Load Average
uptime
or
cat /proc/loadavg
Check CPU Usage
top
or
htop
Check Disk Performance
iostat -x 1
Important fields:
%utilawaitsvctm(older versions)r/sw/s
If:
%utilis consistently near 100%awaitis high
Then the disk is likely saturated.
Find Processes Causing Disk Activity
iotop
or
pidstat -d 1
View System Statistics
vmstat 1
Pay attention to:
- r
- b
- wa
If b (blocked processes) keeps increasing, processes are waiting on I/O.
CPU Bottleneck vs Disk Bottleneck
| CPU Bottleneck | Disk Bottleneck |
|---|---|
| High CPU utilization | Low CPU utilization |
| Low I/O Wait | High I/O Wait |
| High User/System CPU | High Disk Latency |
Check top | Check iostat -x |
| CPU is busy | CPU is waiting |
Understanding this distinction helps you troubleshoot much faster.
Troubleshooting Flow
When a Linux server is slow:
Step 1
Check the Load Average.
uptime
Step 2
Check CPU utilization.
top
Step 3
If CPU isn’t high, check I/O Wait.
vmstat 1
Step 4
Check disk latency.
iostat -x 1
Step 5
Identify the process causing heavy disk usage.
iotop
Step 6
Investigate the application.
Common culprits include:
- MySQL
- PostgreSQL
- Backup jobs
- Log rotation
- Antivirus scans
- Large file copies
Common Mistakes
❌ High Load Average always means CPU overload.
✔ High Load Average simply means many processes are waiting for CPU or I/O.
❌ CPU utilization tells the complete story.
✔ CPU utilization is only one part of system performance.
❌ Ignore Disk I/O because CPU looks healthy.
✔ Storage bottlenecks can make an entire application appear slow, even when CPU usage is low.
Interview Questions to Practice
- What is Load Average?
- Which process states contribute to Load Average?
- Can Load Average be high while CPU utilization is low?
- What is I/O Wait?
- How do you identify a disk bottleneck?
- Which command shows disk latency?
- What is the difference between CPU utilization and Load Average?
- What does a high
awaitvalue indicate iniostat? - What does the D state represent in Linux?
- How would you troubleshoot a production server with a high Load Average?
If you can confidently answer these questions, you’re well prepared for most Linux and DevOps interviews.
Final Thoughts
Linux performance troubleshooting is not about memorizing commands—it’s about understanding how the operating system behaves under load.
Whenever you encounter a slow server, avoid jumping to conclusions based solely on CPU utilization. Always look at the bigger picture:
- Load Average
- CPU Utilization
- I/O Wait
- Disk Latency
- Running Processes
A methodical approach will help you identify the real bottleneck faster and resolve production issues with confidence.
Whether you’re preparing for interviews or managing production infrastructure, mastering these concepts will make you a stronger Linux and DevOps engineer.
If you found this article useful, follow my blog for more practical Linux, AWS, and DevOps guides based on real production experiences.