kb/processes ── Processes & resources ── beginner

Load average

Load average is three numbers in `uptime`: exponential averages of the run-queue length (R + D state) over 1, 5, and 15 minutes. It only makes sense in the context of `nproc`.

view as markdownaka: load-avg, uptime

What load average shows

The uptime command (and the top header) prints three numbers:

load average: 0.45, 0.30, 0.18

These are exponentially weighted averages of the run-queue length, counting processes that were in state R or D at sampling time (see process-and-pid). The averaging windows are the last 1, 5, and 15 minutes.

The value itself is not normalized to the number of CPUs. On a 1-core machine LA=1.0 means "one core is 100% busy". On an 8-core machine the same LA=1.0 means "one of the eight is busy".

Read it in context: LA / nproc < 1.0 means headroom, ~1.0 means at the limit, >>1.0 means something is waiting in the queue (CPU-bound or I/O-bound, see below).

Where the data lives

cat /proc/loadavg gives four fields: 1m 5m 15m running/total last_pid
uptime shows the same, formatted
top / htop update in real time

Note: procs_running in /proc/stat is an instantaneous count of processes ready to run. Unlike LA-1m it is not smoothed and reacts immediately, which is handy for debugging.

R vs D, why a high LA is not always a CPU problem

Processes in the LA queue are the sum of two types:

R (Running/Runnable) wants the CPU
D (Uninterruptible Sleep) is stuck on I/O in the kernel, waiting on disk/NFS/dm

Scenarios at LA=8 on a 4-CPU machine:

8 R, 0 D → the CPU really is overloaded; you need more cores or less work
0 R, 8 D → the CPU is idle, the culprit is the disk (NFS dropped, the DB hung, an md-rebuild). No CPU upgrade will help.

So for any LA problem the first command is ps -eo state,pid,cmd | awk '$1 ~ /^[RD]/'.

In containers

A container shares the kernel with the host, and /proc/loadavg is not containerized. Inside a Docker container you see the LA of the whole host VM, not your own container. For per-container CPU pressure use PSI (Pressure Stall Information) from cgroups v2.

§ команды

bash

uptime

Uptime plus LA-1m, LA-5m, LA-15m

bash

cat /proc/loadavg

Raw values plus procs_running/procs_total plus last_pid

bash

awk -v cores=$(nproc) '{printf "%.2f\n", $1/cores}' /proc/loadavg

Normalized LA-1m (a value < 1 means you have headroom)

bash

ps -eo state,pid,cmd | awk '$1 ~ /^[RD]/'

Only processes in R or D state, the ones that actually drive the LA

bash

cat /sys/fs/cgroup/cpu.pressure

PSI in cgroups v2, CPU pressure for the current container/cgroup; more precise than LA

§ см. также

§ упоминается в уроках

kb/processes ── Processes & resources ── beginner

Load average

Load average is three numbers in `uptime`: exponential averages of the run-queue length (R + D state) over 1, 5, and 15 minutes. It only makes sense in the context of `nproc`.

view as markdownaka: load-avg, uptime

What load average shows

The uptime command (and the top header) prints three numbers:

load average: 0.45, 0.30, 0.18

The value itself is not normalized to the number of CPUs. On a 1-core machine LA=1.0 means "one core is 100% busy". On an 8-core machine the same LA=1.0 means "one of the eight is busy".

Read it in context: LA / nproc < 1.0 means headroom, ~1.0 means at the limit, >>1.0 means something is waiting in the queue (CPU-bound or I/O-bound, see below).

Where the data lives

cat /proc/loadavg gives four fields: 1m 5m 15m running/total last_pid
uptime shows the same, formatted
top / htop update in real time

Note: procs_running in /proc/stat is an instantaneous count of processes ready to run. Unlike LA-1m it is not smoothed and reacts immediately, which is handy for debugging.

R vs D, why a high LA is not always a CPU problem

Processes in the LA queue are the sum of two types:

R (Running/Runnable) wants the CPU
D (Uninterruptible Sleep) is stuck on I/O in the kernel, waiting on disk/NFS/dm

Scenarios at LA=8 on a 4-CPU machine:

8 R, 0 D → the CPU really is overloaded; you need more cores or less work
0 R, 8 D → the CPU is idle, the culprit is the disk (NFS dropped, the DB hung, an md-rebuild). No CPU upgrade will help.

So for any LA problem the first command is ps -eo state,pid,cmd | awk '$1 ~ /^[RD]/'.

In containers

§ команды

bash

uptime

Uptime plus LA-1m, LA-5m, LA-15m

bash

cat /proc/loadavg

Raw values plus procs_running/procs_total plus last_pid

bash

awk -v cores=$(nproc) '{printf "%.2f\n", $1/cores}' /proc/loadavg

Normalized LA-1m (a value < 1 means you have headroom)

bash

ps -eo state,pid,cmd | awk '$1 ~ /^[RD]/'

Only processes in R or D state, the ones that actually drive the LA

bash

cat /sys/fs/cgroup/cpu.pressure

PSI in cgroups v2, CPU pressure for the current container/cgroup; more precise than LA