In Linux or Unix operating system, I am getting the text

System load

as below.

Can anyone please tell me what is the meaning for that and how to extract system load % using CLI commands?

System load: 6.84
  • 3
    What do you mean by getting the text System load? Did you run a command - if so, what was it? – ajgringo619 Nov 21 '19 at 3:41
  • 1
    Note that the load average is not a percentage. It's the average length of the run queue over some time interval. – Kusalananda Nov 21 '19 at 9:26
  • @Kusalananda "length of run queue": So it is seconds? A time length? Or another "length"? What conceptual unit, physically, mathematically? – rastafile Nov 21 '19 at 10:20
  • @rastafile The unit is "number of processes" (in the queue). – Kusalananda Nov 21 '19 at 10:26
  • 2
    @rastafile Computers are fast: the length of each processor's run queue may vary much faster than 60 times per second, so a typical monitor with 60 Hz refresh rate has no hope of showing the actual current queue length, and human eye cannot read it fast enough anyway. So any run queue length displayed must either be a snapshot of some arbitrary moment in time, or an average over some span of time. In this case, the average value is more representative of the overall system workload. E.g. 1.8 could mean the queue length is "mostly 2, but about one time out of five it was 1 instead." – telcoM Nov 21 '19 at 14:09

Please refer to Wikipedia article on Unix-style system load values: https://en.wikipedia.org/wiki/Load_(computing)

In short, if this is a Unix-style load average value, you'll need to divide this value by the number of usable processor cores in the system, and then multiply by 100 to get a percentage value.

As is, the Unix-style load value describes the average number of actually running + waiting-for-CPU processes in a certain time period: commonly three load values are reported, using time windows of 1, 5 and 15 minutes, respectively. On Linux, processes that are waiting for I/O are also counted; on most Unix systems they are not.

If the load value is less than the number of usable processor cores, it means the system was not fully busy within the averaging window, and could handle more work; if the load value is greater than the number of processor cores, it means there was more work than the processors could handle.

In most Unix-like systems (including Linux), you can use the uptime command to get an output like this:

$ uptime
12:11:23 up  5:22,  1 user,  load average: 0.04, 0.05, 0.01

After the words load average: the load values for 1, 5 and 15 minute time windows are displayed.

On Linux, you can get the same information (and depending on kernel version, possibly other information too) by reading the /proc/loadavg virtual file, with e.g. cat /proc/loadavg.

On Linux, you might turn the load average value into a percentage like this, for example:

# uses the 5-minute load value
LOADVAL5=$(awk '{ print $2; }' < /proc/loadavg)
echo "$LOADVAL5 * 100 / $NUMCPUS" | bc

Of course, this script is unoptimized and so not ideal for running repeatedly; if you're developing a monitoring system, you should make the calculation within the program code instead of running an external script for calculating a load percentage.


Regarding your question

how to extract system load % using CLI commands?

on Linux you could Grab the load average with top.


uptime will show the load averages for 1, 5 and 15 minutes (i.e. the number of processes waiting to run, on average, during those time periods) on the Unices that I'm aware of:

$ uptime
 10:27:35 up 21 days, 22:59,  5 users,  load average: 0.13, 0.27, 0.37

You may use awk to parse out the last three fields delimited by commas or colons:

$ uptime | awk -F '[,:]' -v OFS='\n' '{ print $(NF-2),$(NF-1),$NF }'

On Linux, you should be able to query the /proc filesystem for the values with a simple cat:

$ cat /proc/loadavg
0.10 0.07 0.09 1/3794 195765

The fields are explained in the proc manual (man proc on your Linux system):

       The first three fields in this file 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.  They are the
       same as the load average numbers given by uptime(1) and other  pro‐
       grams.   The  fourth  field  consists of two numbers separated by a
       slash (/).  The first of these is the number of currently  runnable
       kernel  scheduling  entities (processes, threads).  The value after
       the slash is the number of kernel  scheduling  entities  that  cur‐
       rently  exist  on  the  system.   The fifth field is the PID of the
       process that was most recently created on the system.

You can use "top" command. By this you will get the PID, user, CPU used etc.

$ top

top - 15:12:59 up  4:43,  4 users,  load average: 0.15, 0.32, 0.30
Tasks: 252 total,   1 running, 203 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2.6 us,  1.3 sy,  0.0 ni, 95.7 id,  0.4 wa,  0.0 hi,  0.0  si,  0.0 st
KiB Mem :  8084528 total,   257360 free,  5410684 used,  2416484  buff/cache
KiB Swap:  8302588 total,  8198908 free,   103680 used.  1410824  availMem  

  • This does show load, but it doesn't help the OP "extract system load [...] using CLI commands". You might want to start with top -b -n1 – roaima Nov 21 '19 at 9:47
  • I wanted to comment, but I see you are just starting...now I see the 3 "load average" top right -- go on! It is about "System Load", and top has a word to say about that...oh well another comment sounds similar... – rastafile Nov 21 '19 at 9:47


The global load average is an exponentially decaying average of nr_running + nr_uninterruptible

This is the perfect answer. Espaecially, because it leads directly to the next question: what is nr_running, and nr_uninterruptible?

I have insisted on percentage -- and still do in the sense of OP -- but the technical answer to (Linux!) "System Load" is this:

The number of "R" tasks. Plus the "D" ones.

"R" is either being run or waiting for it i.e. being in the run queue. "D" is a (special) waiting state - linux includes these tasks, because they represent at least non-CPU "System" load ("mostly IO"), but this is not important here, except that it shows that "System Load" is not directly "CPU Load".

So it is the raw number of tasks/threads competing for the CPUs.

Or the fraction of a task running, in average.

In average...over one of the well-defined time periods of 1, 5 and 15 minutes. Here I insert another chunk, actually the

#define FIXED_1         (1<<FSHIFT)     /* 1.0 as fixed-point */
#define LOAD_FREQ       (5*HZ+1)        /* 5 sec intervals */
#define EXP_1           1884            /* 1/exp(5sec/1min) as fixed-point */
#define EXP_5           2014            /* 1/exp(5sec/5min) */
#define EXP_15          2037            /* 1/exp(5sec/15min) */

 * a1 = a0 * e + a * (1 - e)
static inline unsigned long
calc_load(unsigned long load, unsigned long exp, unsigned long active)
        unsigned long newload;

        newload = load * exp + active * (FIXED_1 - exp);
        if (active >= load)
                newload += FIXED_1-1;

        return newload / FIXED_1;

Now for a normal-sized HZ of "333" (between 100-1000) this gives 1666+1. For a one-minute average a five-second sampling rate is very nice: one dozen samples per minute for a per minute average.

This comment a1 = a0 * e + a * (1 - e) shows the whole beauty: The sampled "a" (for "active", see calc_load() below) is combined with a0 (load) into a (newload).

What the FIXED_1 is for I can't say. I take "1.0 as fixed point" as a hint to ask:

So what about System Load in %, please?

To make it simple I say: One CPU can serve one thread at a time.

A bit complicated: One "quadcore" "multi/hyperthread/-ripping" CPU can be 8 CPUs, or more, to the kernel. This is the "SMP" implementation.

Even more: quadcore still is 4 and not eight. Intel talks of 120% percent typical benfit through hyperthreading, as they call theirs. Not 200%.

So a load average of 6.8, as a percentage on above quadcore / cpu0-7 system would mean:

Over the corresponding period (last 1,5 or 15 min.), on average, almost 7 threads were running. With 8 CPUs this looks like 87% system load. But 4 of these 8 CPUs are "hyper"threading, parallelizing at the cost of throughput already.

6.8 would be rather slightly above 100%, than under.

To avoid all this task-to-core mapping questions, the load average is a raw "R" (plus "D") state count.

In above example, for x86, I would use 4 as a reference for "100%", i.e. the point where no thread has to wait, and no core is sitting idle, not even for a couple of nano seconds. "Well balanced" that would be. Any additional load leads to a slight overload of CPU, above 100%, or above 4 or even 8.

Because with 9 running thread on a 2 times 4 core system. then definately one of them can not run at any given time. So there is some theoretical 100% line you can draw -- somehere between the number of cores and that nr times threads per core.

This is why I upvoted this Q. I could slap myself only for defending the "percentage" interpretation so much. Not because it is sooo wrong, but because I wasted too much time when the man page and the kernel source explain it so well.

I leave everything below as is -- maybe a bit on the side "see, it is a percentage also, and in essence" -- but

Guess what: man uptime explains in a couple of lines. And I discuss here percent calculation like a 10 year old child.

Load averages are not normalized for the number of CPUs in a system, so a load average of 1 means a single CPU system is loaded all the time while on a 4 CPU system it means it was idle 75% of the time.

Here is a central part of telcoM's link, i.e. the wikipedia article "Load (computing)".

For example, one can interpret a load average of "1.73 0.60 7.98" on a single-CPU system as:

  • during the last minute, the system was overloaded by 73% on average (1.73 runnable processes, so that 0.73 processes had to wait for a turn for a single CPU system on average).
  • during the last 5 minutes, the CPU was idling 40% of the time on average.
  • during the last 15 minutes, the system was overloaded 698% on average (7.98 runnable processes, so that 6.98 processes had to wait for a turn for a single CPU system on average).

No use re-explaining. The three examples are well chosen.

I will upvote telcoM, for the link and his precise summary.

BTW the "exponential dampening" is easy to understand - I think listening to the slow fade out of a tuning fork (or ...) is a perfect comparison.

uptime is valuable because it gives you these three values, telling you how it looks "right now" (last couple of seconds / one minute), what was going on "recently" i.e. the last five minutes, and what is the "summary" of the last 5-20 minutes.

The wiki example means:

Right now, system load is high. Before, for some minutes, it was very low. But even before, there was a very high-load phase over several minutes. Either very high for 10 minutes, or very very high for 5 minutes.

In a 3x3 matrix:

x_X: wiki example, e.g. 100,0,255: purple-blue: "load" after "idle" after "overload"

Xx_: 255,100,0: orange: overload after load after idle

_xX: 0,100,255: cyan-blue: now idle, after load, after overload

x__: 100,0,0: dark red: now load, before idle for 15 minutes.

___: black: full idle

xxx: grey (or white): balanced

XXX: white (or bold white): glowing brightly

--> no color means no load change over the last 15 minutes

(No I don't have a bash prompt function for that, yet)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.