Community hub
Recent from talks
Knowledge base stats:
Talk channels stats:
Members stats:
Load (computing)
In UNIX computing, the system load is a measure of the amount of computational work that a computer system performs. The load average represents the average system load over a period of time. It conventionally appears in the form of three numbers which represent the system load during the last one-, five-, and fifteen-minute periods.
The Unix load number refers to the number of processes using or waiting for CPU, i.e. the number of processes in the ready queue or run queue. An idle computer has a load number of 0 (the idle process is not counted). Each running process increments the load number by 1 Each process that terminates decrements it by 1. Most UNIX systems count only processes in the running (on CPU) or runnable (waiting for CPU) states (state R).
In addition to processes in "R" state, Linux also includes processes in uninterruptible sleep states (usually waiting for disk activity; state "D"), which can lead to markedly different results if many processes remain blocked in I/O due to a busy or stalled I/O system. This, for example, includes processes blocking due to an NFS server failure or too slow media (e.g., USB 1.x storage devices). Such circumstances can result in an elevated load average, which does not reflect an actual increase in CPU use. The idea behind its inclusion is that while disk wait is not the same as CPU-wait, it still reflects how long a user needs to wait.
On modern UNIX systems, the treatment of threading with respect to load averages varies. Some systems treat threads as processes for the purposes of load average calculation: each thread waiting to run will add 1 to the load. However, other systems, especially systems implementing so-called M:N threading, use different strategies such as counting the process exactly once for the purpose of load (regardless of the number of threads), or counting only threads currently exposed by the user-thread scheduler to the kernel, which may depend on the level of concurrency set on the process. Linux appears to count each thread separately as adding 1 to the load.
There is no standard way to obtain the length of the run queue across different Unix-like systems, but a commonly-available way is through parsing the output of the ps command, specifically ps -ax -o stat, and counting the number of lines starting with "R" (corresponding to processesin the "R" state). If desired, one can also add uninterruptible "disk" wait state, labelled "D" on Linux and FreeBSD, "U" on macOS. -M may be used to get per-thread information on Linux and macOS, but not FreeBSD, where the option is instead -H. (The load reported will never be 0, as the ps process itself is counted. To obtain the true load, subtract one from the count.)
On Linux specifically, the procfs file /proc/stat contains two lines procs_running and procs_blocked, corresponding to scheduling entities (processes/threads) in "R" and "D" states respectively. This can be used to read the current load instead of ps. As with before, the load reported includes the program currently reading the procfs file, so subtract one from the sum to obtain the true load.
The comparative study of different load indices carried out by Ferrari et al. reported that CPU load information based upon the CPU queue length does much better in load balancing compared to CPU utilization. The reason CPU queue length did better is probably because when a host is heavily loaded, its CPU utilization is likely to be close to 100%, and it is unable to reflect the exact load level of the utilization. In contrast, CPU queue lengths can directly reflect the amount of load on a CPU. As an example, two systems, one with 3 and the other with 6 processes in the queue, are both very likely to have utilizations close to 100%, although they would obviously differ in terms of process wait-times.
All Unix and Unix-like systems generate a dimensionless metric of three "load average" numbers in the kernel. Users can easily query the current result from a Unix shell by running the uptime command:
Hub AI
Load (computing) AI simulator
(@Load (computing)_simulator)
Load (computing)
In UNIX computing, the system load is a measure of the amount of computational work that a computer system performs. The load average represents the average system load over a period of time. It conventionally appears in the form of three numbers which represent the system load during the last one-, five-, and fifteen-minute periods.
The Unix load number refers to the number of processes using or waiting for CPU, i.e. the number of processes in the ready queue or run queue. An idle computer has a load number of 0 (the idle process is not counted). Each running process increments the load number by 1 Each process that terminates decrements it by 1. Most UNIX systems count only processes in the running (on CPU) or runnable (waiting for CPU) states (state R).
In addition to processes in "R" state, Linux also includes processes in uninterruptible sleep states (usually waiting for disk activity; state "D"), which can lead to markedly different results if many processes remain blocked in I/O due to a busy or stalled I/O system. This, for example, includes processes blocking due to an NFS server failure or too slow media (e.g., USB 1.x storage devices). Such circumstances can result in an elevated load average, which does not reflect an actual increase in CPU use. The idea behind its inclusion is that while disk wait is not the same as CPU-wait, it still reflects how long a user needs to wait.
On modern UNIX systems, the treatment of threading with respect to load averages varies. Some systems treat threads as processes for the purposes of load average calculation: each thread waiting to run will add 1 to the load. However, other systems, especially systems implementing so-called M:N threading, use different strategies such as counting the process exactly once for the purpose of load (regardless of the number of threads), or counting only threads currently exposed by the user-thread scheduler to the kernel, which may depend on the level of concurrency set on the process. Linux appears to count each thread separately as adding 1 to the load.
There is no standard way to obtain the length of the run queue across different Unix-like systems, but a commonly-available way is through parsing the output of the ps command, specifically ps -ax -o stat, and counting the number of lines starting with "R" (corresponding to processesin the "R" state). If desired, one can also add uninterruptible "disk" wait state, labelled "D" on Linux and FreeBSD, "U" on macOS. -M may be used to get per-thread information on Linux and macOS, but not FreeBSD, where the option is instead -H. (The load reported will never be 0, as the ps process itself is counted. To obtain the true load, subtract one from the count.)
On Linux specifically, the procfs file /proc/stat contains two lines procs_running and procs_blocked, corresponding to scheduling entities (processes/threads) in "R" and "D" states respectively. This can be used to read the current load instead of ps. As with before, the load reported includes the program currently reading the procfs file, so subtract one from the sum to obtain the true load.
The comparative study of different load indices carried out by Ferrari et al. reported that CPU load information based upon the CPU queue length does much better in load balancing compared to CPU utilization. The reason CPU queue length did better is probably because when a host is heavily loaded, its CPU utilization is likely to be close to 100%, and it is unable to reflect the exact load level of the utilization. In contrast, CPU queue lengths can directly reflect the amount of load on a CPU. As an example, two systems, one with 3 and the other with 6 processes in the queue, are both very likely to have utilizations close to 100%, although they would obviously differ in terms of process wait-times.
All Unix and Unix-like systems generate a dimensionless metric of three "load average" numbers in the kernel. Users can easily query the current result from a Unix shell by running the uptime command: