Understanding Linux Load Average, CPU and Memory Usage
What Linux load average really measures, how to read CPU and memory figures including buff/cache and available memory, and when high numbers are actually a problem.
Table of Contents
On Linux, load average is the average number of processes that are either running or waiting to run (including those waiting for disk I/O) over the last 1, 5 and 15 minutes. As a rule of thumb, a load average consistently above the number of CPU cores means work is queuing. For memory, the number to watch is "available", not "free": Linux deliberately uses spare RAM as disk cache and gives it back when applications need it.
Misreading these numbers leads to two common mistakes: panicking about "no free memory" on a healthy server, and missing a real CPU or I/O bottleneck. Here is how to read them correctly.
Load average
Run uptime or look at the top line of top:
load average: 1.20, 0.85, 0.60
The three numbers are the 1-, 5- and 15-minute averages. Compare them with the number of CPUs (nproc):
| Load vs CPUs (4 vCPUs) | What it suggests |
|---|---|
| 0.5 – 2 | Comfortable |
| Around 4 | Fully used; little headroom |
| 6 – 8 sustained | Work is queuing; responses slow down |
| Rising 1-min, low 15-min | A recent spike |
| High 15-min | A sustained problem |
Linux load includes processes waiting for disk (state "D"), not only CPU. A high load with low CPU usage usually points to slow storage or I/O waits, not a CPU shortage.
CPU usage breakdown
In top, the %Cpu(s) line splits CPU time:
- us: user processes (your applications, PHP, database);
- sy: kernel work;
- wa: time CPUs waited for I/O; consistently high means storage is a bottleneck;
- st: steal time, on virtual machines: time the hypervisor gave your vCPU to someone else. Consistently high steal means the host is busy;
- id: idle.
On multi-core servers, per-process CPU in top can exceed 100% (100% = one core).
Memory: free vs available
Run free -h:
total used free shared buff/cache available
Mem: 7.7Gi 2.1Gi 0.4Gi 0.1Gi 5.2Gi 5.3Gi
Swap: 2.0Gi 0.0Gi 2.0Gi
- free: memory not used for anything. A low number is normal.
- buff/cache: memory holding disk cache. It speeds up file and database access and is released when needed.
- available: an estimate of memory applications can still use. This is the number that matters.
The server above is healthy: only 0.4 GiB is "free", but 5.3 GiB is available.
When memory is really short
- available stays very low;
- swap used keeps growing and the server feels sluggish;
- the kernel log shows the OOM killer stopping processes (
dmesgorjournalctl -kmentions "Out of memory: Killed process").
Typical causes are too many PHP-FPM workers, an oversized database buffer pool, or a memory leak. See Linux swap space explained and server performance tuning.
Putting it together: common patterns
| Pattern | Likely cause |
|---|---|
High load, high us, low wa |
CPU-bound: heavy PHP, queries or processing |
High load, low us, high wa |
Storage bottleneck |
High load, high st |
Busy virtualisation host |
| Low available memory, swap growing | Memory pressure |
| Load spikes at fixed times | Cron jobs, backups, scheduled imports |
Worked example: high load, idle CPU
A 4 vCPU server shows a load average of 9, but top shows CPU usage around 20% user and 60% wa. The CPUs are mostly waiting, not working.
iostat -x 2shows the disk at nearly 100% utilisation with long wait times.sudo iotop -oshows a backup job compressing and copying several gigabytes, started by cron at the same time every day.- The database queries that normally take milliseconds now wait behind the backup's disk I/O, so web requests pile up, raising the load.
The fix is not more CPU: reschedule the backup to a quieter time, lower its I/O priority (ionice -c3), or move it off the server. Load returns to normal immediately.
This is why load average must always be read together with the CPU breakdown: the same number can mean "not enough CPU" or "slow disk".
Pressure stall information (PSI)
Modern Linux kernels expose pressure stall information in /proc/pressure/cpu, /proc/pressure/memory and /proc/pressure/io. It reports the percentage of time tasks were delayed waiting for each resource:
cat /proc/pressure/memory
some avg10=5.00 means some tasks were stalled on memory 5% of the time in the last 10 seconds. PSI is a more direct measure of "is this resource holding work back?" than load average, and monitoring tools increasingly use it.
What to do next
- Find the processes responsible with
toporhtop, sorted by CPU or memory. - Check what changed recently: deploys, traffic, cron jobs.
- Check logs for errors and the database slow query log.
- Decide whether to optimise, reschedule work, or add resources. See how to choose VPS specs.
Step-by-step commands are in how to check server resource usage.
Frequently Asked Questions
Is a load average of 1.0 bad?
On a single-core server it means the CPU is fully used. On a 4-core server it is light. Always compare with the number of cores.
Why does Linux use all my memory?
It uses spare memory for disk caching to speed things up, and frees it when applications need it. Watch "available", not "free".
What is steal time?
On a virtual machine, time your virtual CPU wanted to run but the hypervisor ran another workload. Persistent high steal means the physical host is contended.
Related reading
For an overview of monitoring, see server monitoring basics, and for the fundamentals, what is a VPS. Compare the ServerNeed VPS plans.
Sources
Last updated 7 October 2026
