Understanding System Load Average and Its Interpretation
The article explains how Unix-like systems calculate load average using an exponentially damped weighted moving average, how the values reflect CPU and I/O contention on single- and multi‑CPU machines, and why different kernel implementations may count processes and threads differently, affecting performance monitoring.
Idle computers have a load value of 0; each process that uses or waits for the CPU (in the runnable or running queue) increments the load by 1. Most UNIX systems count only running (on‑CPU) or runnable (waiting for CPU) processes, while Linux also includes processes in an uninterruptible sleep state (e.g., waiting for disk I/O). In I/O‑heavy systems many blocked processes can inflate the load value, reflecting user‑perceived wait time rather than actual CPU usage.
The system computes load using an exponentially damped/weighted moving average—a digital filter—to produce three load values representing the average over the past 1, 5, and 15 minutes.
On a single‑CPU system, which is CPU‑bound, the average load can be interpreted as the percentage of CPU utilization. For multi‑CPU systems, the load must be divided by the number of processors to obtain a comparable percentage.
For example, on a single‑CPU machine the load string "1.73 0.60 7.98" means: in the last minute the system was 73 % overloaded (1.73 runnable processes, so 0.73 processes were waiting); over the last five minutes the CPU was idle about 40 % of the time; and over the last fifteen minutes the system was 698 % overloaded (7.98 runnable processes, so 6.98 were waiting).
This implies that in the past minute the system would need to be 1.73 times faster (CPU, disk, memory, etc.) to handle all scheduled work. In a four‑CPU system, a load of 3.73 indicates that on average 3.73 processes are ready to run, each of which can be scheduled onto a CPU.
Modern UNIX variants handle load calculation differently. Some systems treat each waiting thread as a process, adding 1 to the load for every thread awaiting execution. Others, especially those using M:N thread scheduling, may only add 1 per process regardless of thread count, or count only threads that have entered the kernel, depending on the configured concurrency level.
Many systems periodically sample scheduler state to compute load instead of recounting every scheduling event, for performance reasons because scheduling events occur frequently and affect overall system efficiency. Sampling errors can cause the reported load to diverge from actual system behavior, which can be problematic for programs that run at fixed intervals and rely on accurate load values.
English original: http://en.wikipedia.org/wiki/Load_(computing)#cite_note-drdobbs-1
Translator: Zhou Tong
Author: Zhou Tong, Core Engineer of the Hotel Business Unit at Qunar, graduate of Harbin Institute of Technology.
Article originally from the company wiki "One Thousand and One Nights of the Hotel Development Team"; Qunar colleagues can log into the wiki to view more articles.
Qunar Tech Salon
Qunar Tech Salon is a learning and exchange platform for Qunar engineers and industry peers. We share cutting-edge technology trends and topics, providing a free platform for mid-to-senior technical professionals to exchange and learn.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.