Linux load average explained

What it means

A runnable task is executing or ready to execute. Tasks in some uninterruptible waits, such as certain storage waits, also contribute to Linux load. These are different conditions: needing processor time is not the same as waiting for another resource.

Load combines those contributions into an average, so the number does not reveal how many contributing tasks were actually using a CPU. The lab uses the five-minute load value and an entered logical CPU count to explore that distinction.

Try it

Simulation: start with Five-minute load average = 4 and Available logical CPUs = 4. Change Available logical CPUs to 8, then inspect the result and its explanation. Select Compare with baseline to display the starting and current ratios together. You are changing a local teaching input, not a real machine.

Load / logical CPU = 1.00. A load average of 4 against 4 logical CPUs gives a comparison ratio, not a measured percent of CPU utilization. Inspect runnable/wait states.

Keep Five-minute load average at 4. Only Available logical CPUs changes, from 4 to 8; the scene has no task-state or CPU-utilization input.

Reset restores Five-minute load average to 4 and Available logical CPUs to 4, removes input errors and clears the comparison. There is no running clock or stored event history to reset. Your independently opened or closed FAQ answers and About this model panel stay as you left them.

How it works

The calculation is:

comparison ratio = five-minute load average ÷ available logical CPUs

The numerator is an averaged task count; the denominator is a processor count. Dividing gives a scale comparison, but it does not classify the contributing tasks. In particular, dividing by more CPUs does not remove uninterruptible waiting work from the numerator.

That missing classification is why the same ratio can support different investigations. Runnable work may be competing for processor time. Tasks in certain storage waits can also contribute to load without keeping every CPU busy. The load value combines those contributions rather than telling you which condition dominates.

The lab changes only the arithmetic comparison. It does not simulate how a workload would respond to additional CPUs. A time-aligned view of task states, CPU utilization and resource pressure is needed before turning the ratio into an explanation of a slowdown.

Worked example

This is a synthetic baseline, not a captured production observation.

The calculation is 4 ÷ 4 = 1.00. The equal numbers make it tempting to infer that all four CPUs are fully occupied. But the load input does not say how much of its averaged count came from runnable work and how much came from contributing waits. The arithmetic is established; CPU saturation is not.

What changes when the condition changes

Change Available logical CPUs from 4 to 8 while keeping Five-minute load average at 4. The result becomes Load / logical CPU = 0.50: 4 ÷ 8 = 0.50.

The ratio halves because its denominator doubles, not because the entered load falls. No task-state evidence has been supplied, and editing this field does not add processors to a real machine. If the contributing tasks were waiting for storage rather than processor time, this lower ratio would still not establish that their wait had improved.

In practice

On a Linux system you are authorized to inspect, begin with read-only observations for the affected workload and time period. Record its load reading and averaging timescale, CPU availability, CPU utilization, runnable or waiting task states, and the symptom you are investigating. Use existing monitoring or permitted system information; this example does not require a configuration change.

Check the scope before comparing numbers. A host-wide processor count does not establish the scheduling limits of a constrained workload. Likewise, observations from different periods cannot reliably explain the same slowdown.

Look for the condition behind the count. Runnable work alongside busy CPUs supports investigating processor contention; contributing waits alongside low CPU utilization support investigating waiting elsewhere. Neither pattern alone identifies a particular faulty component. Resource-pressure evidence can help, but it must be interpreted within its own documented scope.

Stop short of a capacity recommendation if the task states, CPU limits or matching time-period evidence are missing. Do not change CPU allocation or service settings solely because of this ratio. This is an interpretation exercise, not a procedure for modifying a server.

Limits and unknowns

The controls accept a Five-minute load average from 0 to 64, with a labeled increment of 0.1, and Available logical CPUs from 1 to 64. These are teaching-model bounds, not limits on real Linux systems. If an input is invalid, the calculated outcome is removed until you correct it or use Reset; the previous valid result does not stand in for the visible input.

A valid arithmetic result still leaves the cause unknown. The model has no evidence about task-state mix, scheduling restrictions, actual processor use or application response time. It cannot diagnose a bottleneck, predict a speedup or declare a service healthy.

All calculation is local. The scene does not inspect a machine, run a command, contact a server or change CPU resources. Without JavaScript, the initial example and explanation remain readable, but the controls do not operate. For the Linux definition, see proc_loadavg(5), DESCRIPTION, in the supplied sources.

What to carry forward

Treat load as a clue about runnable and waiting work, not a CPU-capacity verdict. Before choosing a remedy, establish whether the affected workload was competing for processor time or waiting elsewhere. If that evidence is missing, the justified next step is observation—not adding CPUs because a ratio crossed a threshold.