Read Linux Load Averages Directly from /proc/loadavg

You will finish with a small, repeatable way to read the current Linux load averages, separate the runnable count from the total scheduling-entity count, and identify the most recently created PID. The examples use the format documented by Linux man-pages 6.7, installed here through Debian package manpages version 6.7-2.

Allow about ten minutes. You need a shell and a Linux system with /proc mounted. Everything below is read-only and should normally run as your ordinary user. No sudo, service restart or configuration change is needed.

1. Read the file once

Run this first:

$ cat /proc/loadavg
3.48 4.27 4.03 9/3162 3718535

Your numbers will change. The line has five whitespace-separated fields, but the fourth field contains a second pair of numbers separated by /. Do not treat the whole line as five independent decimal values.

Checkpoint: confirm that the file is present and readable without changing anything:

$ test -r /proc/loadavg && echo readable
readable

If this prints nothing, the test failed. Check that you are on Linux and that the proc filesystem is mounted. A missing or unusual /proc mount is an environment problem; adding a mount is outside this read-only guide.

2. Interpret the three averages

The first three fields are load averages over one, five and fifteen minutes, in that order. They count jobs either in the run queue, state R, or waiting for disk I/O, state D. The same figures are exposed by uptime and other monitoring tools.

These are not percentages and they are not a count of CPU usage. A job blocked in uninterruptible disk I/O contributes to the load even though it is not actively consuming CPU. A high first value with lower five- and fifteen-minute values can indicate a recent burst. Similar values across all three windows indicate that the condition has lasted longer.

Do not copy a universal alarm threshold into a script. The useful comparison depends on the host's workload, storage and number of CPUs. Treat the three values as a trend, then check CPU, memory, storage and process-level evidence before deciding that a machine is unhealthy.

3. Split the runnable and total counts

The fourth field has the form runnable/total. The first number is the number of currently runnable kernel scheduling entities. The second is the number of kernel scheduling entities that currently exist. The documented entities include processes and threads, so this is not necessarily the same as the number of processes shown by a process-listing command.

Use awk to print the fields with names. This reads the file once and does not need elevated privileges:

$ awk '{ split($4, count, "/"); printf "1m=%s 5m=%s 15m=%s runnable=%s total=%s newest_pid=%s\n", $1, $2, $3, count[1], count[2], $5 }' /proc/loadavg
1m=3.48 5m=4.27 15m=4.03 runnable=9 total=3162 newest_pid=3718535

The sample output is from one reading and is only illustrative. On your host, the values and the PID will differ. The command's useful checks are that three load values appear, the fourth field is divided at one slash, and the fifth field is retained as an integer-looking PID.

Checkpoint: compare the load averages with the command-line view without assuming the two reads are simultaneous:

$ cat /proc/loadavg
3.48 4.27 4.03 9/3162 3718535
$ uptime
 10:20:00 up 3 days,  2:14,  2 users,  load average: 3.48, 4.27, 4.03

uptime may format its surrounding text differently. Compare only its three load values. A small difference is normal because the files are read at different moments.

4. Use the newest PID as a clue, not proof

The fifth field is the PID of the process most recently created on the system. It is useful when correlating a busy period with process creation, but it is not a process identity guarantee. PIDs can be reused after a process exits, and the process may have disappeared by the time you inspect it.

Read the value, then inspect it immediately if it still exists:

$ newest_pid=$(awk '{print $5}' /proc/loadavg)
$ printf 'newest PID reported: %s\n' "$newest_pid"
newest PID reported: 3718535
$ if test -r "/proc/$newest_pid/comm"; then cat "/proc/$newest_pid/comm"; else echo 'process no longer exists'; fi
worker

The process name in this example is host-specific. The conditional avoids turning a normal race into an error: a short-lived process can exit between the two reads. Do not use this field alone to attribute load or to kill a process.

5. Record a short sample safely

For a simple trend, take a few read-only samples rather than relying on one line. This loop prints the raw record every five seconds and stops after three readings:

$ for sample in 1 2 3; do
>   date '+%H:%M:%S'
>   cat /proc/loadavg
>   test "$sample" -eq 3 || sleep 5
> done
10:20:00
3.48 4.27 4.03 9/3162 3718535
10:20:05
3.52 4.25 4.02 8/3163 3718538
10:20:10
3.50 4.24 4.02 7/3163 3718538

The timestamps and values will differ. The loop does not write a file, alter scheduling and require no root access. If you need a longer record, redirect its output to a new, explicitly chosen file. Redirection with > truncates an existing file, so use >> only when appending to a destination you have checked.

6. Avoid the common interpretation traps

• Do not call the first number CPU percentage. It is a load average of runnable and disk-I/O-waiting jobs.
• Do not discard the slash in field four. It separates currently runnable entities from all existing entities.
• Do not compare the load number with a CPU count as if that were a universal pass or fail test. Use the host's workload and supporting measurements.
• Do not expect two commands to show identical results. Each read is a new snapshot and processes can start or exit between reads.
• Do not add sudo to a read-only check. If ordinary access fails, investigate the proc mount or container environment instead.