load average, one command per page
Twenty-eight lessons on load average, one command or file per page: uptime's one line, the 1, 5 and 15 minute windows and the pretty and since forms; /proc/loadavg's five fields, the runnable slash entities pair, the last pid and the R and D states it counts; w's header, the eight user columns, JCPU against PCPU and the -s, -h and -f trims; top's load line, the Tasks census, the %Cpu(s) line and batch mode; mpstat's %idle, the row that must total 100, per-processor rows and interval runs; sar -q's ldavg columns, runq-sz against plist-sz, the blocked column and the daily sa files; and pressure stall information's some and full lines for cpu, memory and io, one real command per page.
One command, one file, one real number. That's a page.
load average, one command per page
Twenty-eight lessons on load average, one command or file per page: uptime's one line, the 1, 5 and 15 minute windows and the pretty and since forms; /proc/loadavg's five fields, the runnable slash entities pair, the last pid and the R and D states it counts; w's header, the eight user columns, JCPU against PCPU and the -s, -h and -f trims; top's load line, the Tasks census, the %Cpu(s) line and batch mode; mpstat's %idle, the row that must total 100, per-processor rows and interval runs; sar -q's ldavg columns, runq-sz against plist-sz, the blocked column and the daily sa files; and pressure stall information's some and full lines for cpu, memory and io, one real command per page.
Set in Space Grotesk, Inter and JetBrains Mono (SIL Open Font License).
Every fact in this book is as the official source states it, fetched and read during this build: the Linux man-pages man7.org pages for uptime(1), w(1) and top(1) from procps-ng, and proc_loadavg(5); the kernel's own Documentation filesystems/proc.rst and accounting/psi.rst from kernel.org; and the sysstat package's own manual pages for mpstat(1) and sar(1) as shipped on this machine (sysstat 12.6.1). No facts are sourced from Reddit, Stack Overflow or vendor blogs. Every command and output pair on every page was run on this machine (procps-ng 4.0.4, sysstat 12.6.1, kernel 6.8.0-147-generic) and confirmed before printing. An independent guide, not affiliated with or endorsed by the Linux man-pages maintainers, the procps-ng or sysstat projects, or the Linux kernel developers.
Your purchase is for personal use only. You do not have redistribution rights: please do not share, resell, or republish this book or its pages.
© 2026 Steve Hodgkiss. All rights reserved. Personal use only; no redistribution rights.
Edition 1.0 · stevehodgkiss.net
Contents
Per Linux man-pages uptime(1) (procps-ng): uptime gives a one line display of the following information, the current time, how long the system has been running, how many users are currently logged on, and the system load averages for the past 1, 5, and 15 minutes; this is the same information contained in the header line displayed by w(1).
uptime's one line
One command, four facts in a fixed order: the time now, how long the system has been up, how many users are logged on, and the load averages for the past 1, 5 and 15 minutes.
Our run: 19:05:53, up 5 days 5:21, 0 user, 0.39, 0.33, 0.28. A server with nobody logged on: 0 user is the honest count.
Per uptime(1), this same line is the header that w(1) prints above its user table.
Run uptime and label the four facts on your own line: time, up, users, load averages.
Per Linux man-pages proc_loadavg(5): the first three fields in /proc/loadavg are load average figures giving the number of jobs in the run queue (state R) or waiting for disk I/O (state D) averaged over 1, 5, and 15 minutes, the same as the load average numbers given by uptime(1) and other programs; the fourth field consists of two numbers separated by a slash; the fifth field is the PID of the process that was most recently created on the system.
cat /proc/loadavg
The file behind every load number: our run printed 0.39 0.33 0.28 4/353 2619784, five fields, space separated.
The first three are the averages uptime(1) prints, from the same kernel counters. The fourth is a pair split by a slash, and the fifth is the most recent pid.
uptime shows three of the five fields: this file is where the other two live.
Run cat /proc/loadavg and name the five fields aloud before reading the next pages.
Per Linux man-pages w(1): the JCPU time is the time used by all processes attached to the tty; it does not include past background jobs, but does include currently running background jobs; the PCPU time is the time used by the current process, named in the what field.
JCPU and PCPU
JCPU is the time used by all processes attached to the tty: past background jobs excluded, currently running background jobs included.
PCPU is narrower: the time of the current process, the one named in the WHAT field.
JCPU is the session's bill, PCPU the front process's: the gap between them is your background work.
In a terminal run a command for ten seconds, then w, and see your PCPU jump to the running command.
Per Linux man-pages top(1): line 2 of the task and CPU states shows CPU state percentages based on the interval since the last refresh, where us is time running un-niced user processes, sy time running kernel processes, ni time running niced user processes, id time spent in the kernel idle handler, wa time waiting for I/O completion, and st time stolen from this vm by the hypervisor. This machine's first batch interval printed 19.3 us, 15.8 sy, 0.0 ni, 63.2 id, 0.0 wa, 1.8 si, 0.0 st.
The %Cpu(s) line
The CPU percentages cover the interval since the last refresh, not since boot. Our first batch interval: 19.3 us, 15.8 sy, 0.0 ni, 63.2 id, 0.0 wa, 1.8 si, 0.0 st.
Per the manual: us un-niced user time, sy kernel time, id the kernel idle handler, wa waiting for I/O completion, st stolen by the hypervisor.
wa is the CPU-side face of the D-state waits that lift load: watch it when load and idle rise together.
Run top -bn1 twice and watch the %Cpu(s) line change between intervals while the load line barely moves.
Per the sysstat package's mpstat(1) manual (sysstat 12.6.1): mpstat writes to standard output activities for each available processor, with global average activities among all processors also reported; the interval parameter specifies the amount of time in seconds between each report, and a value of 0 (or no parameters at all) indicates that processors statistics are to be reported for the time since system startup (boot); %idle is the percentage of time that the CPU or CPUs were idle and the system did not have an outstanding disk I/O request. This machine's boot-long run printed %usr 4.34, %sys 1.63, %iowait 0.29, %idle 93.48.
mpstat's %idle
mpstat with no arguments reports since system startup: our line averaged five whole days into 93.48 %idle, with 4.34 %usr, 1.63 %sys, 0.29 %iowait.
Read %idle precisely: idle and no outstanding disk I/O request. The waiting-on-disk share sits in its own %iowait column.
One line, the machine's whole life: the calmest possible baseline.
Run mpstat with no arguments and write down the since-boot %idle; that is your machine's whole-life average.
Per the sysstat package's sar(1) manual (sysstat 12.6.1): with the LOAD keyword, queue length and load averages statistics are reported; ldavg-1 is the system load average for the last minute, calculated as the average number of runnable or running tasks (R state) and the number of tasks in uninterruptible sleep (D state) over the specified interval; ldavg-5 and ldavg-15 cover the past 5 and 15 minutes. This machine's day replay ended with an Average row of runq-sz 1, plist-sz 339, ldavg 0.32 0.31 0.29, blocked 0, and a 02:50 sample peaking at ldavg-1 1.65.
sar -q
sar -q replays today's collected samples: the same load averages, with history. Our day's Average row: 0.32, 0.31, 0.29.
The definition matches the kernel's own: ldavg counts R-state and D-state tasks, averaged per window. Our noisiest minute was 02:50, ldavg-1 1.65.
uptime shows you now; sar shows you the day. Load incidents leave a trail.
Run sar -q and find your day's busiest minute in the ldavg-1 column.
Per kernel Documentation accounting/psi.rst: pressure information for each resource is exported through the respective file in /proc/pressure, cpu, memory, and io; the some line indicates the share of time in which at least some tasks are stalled on a given resource; the ratios are tracked as percentages over ten, sixty, and three hundred second windows, with the total absolute stall time in us; CPU full is undefined at the system level, but has been reported since 5.13, so it is set to zero for backward compatibility. This machine, kernel 6.8, printed cpu some avg10=0.02 avg60=0.09 avg300=0.31 total=4625881728 and cpu full all zeros with total=0.
/proc/pressure/cpu
The file every kernel since 4.20 carries: /proc/pressure/cpu. Ours reads some avg10=0.02 avg60=0.09 avg300=0.31, total 4625881728 us stalled since boot.
some is the share of time at least some tasks were stalled. The windows are 10, 60, 300 seconds, percentages, not task counts.
Our full line is zeros: system-level CPU full is undefined by design, zeroed since 5.13 for compatibility.
Run cat /proc/pressure/cpu and note which of avg10, avg60 or avg300 is highest: that is your stall trend.