Load - Revision history

90.191.126.115 at 00:11, 27 June 2010

2010-06-27T00:11:38Z

90.191.126.115 at 00:08, 27 June 2010

2010-06-27T00:08:11Z

90.191.126.115 at 00:07, 27 June 2010

2010-06-27T00:07:20Z

90.191.126.115 at 00:03, 27 June 2010

2010-06-27T00:03:12Z

New page

All Unix and Unix-like systems generate a [[Software metric|metric]] of three "load average" numbers in the [[kernel (computer science)|kernel]]. Users can easily query the current result from a [[Unix shell]] by running the <tt>[[uptime]]</tt> command:

$ uptime
09:53:15 up 119 days, 19:08, 10 users, load average: 3.73 7.98 0.50

The [[W (Unix)|<tt>w</tt>]] and [[Top (Unix)|<tt>top</tt>]] commands show the same three load average numbers, as do a range of [[graphical user interface]] utilities. In [[GNU/Linux]], they can also be accessed by reading the <code>/proc/loadavg</code> file.

An idle computer has a load number of 0 and each [[process (computing)|process]] using or waiting for [[Central processing unit|CPU]] adds to the load number by 1. Most UNIX systems count only processes in the ''running'' (on CPU) or ''runnable'' (waiting for CPU) [[Process states | states]]. However, Linux also includes processes in [[uninterruptible sleep]] states (usually waiting for [[Hard disk|disk]] activity), which can lead to markedly different results if many processes remain blocked in [[Input/output|I/O]] due to a busy or stalled I/O system. This, for example, includes processes blocking due to an [[Network File System (protocol)|NFS]] server failure or to slow [[Data storage device|media]] (e.g., [[Universal Serial Bus|USB]] 1.x storage devices). Such circumstances can result in an elevated load average, which does not reflect an actual increase in CPU use (but still gives an idea on how long users have to wait).

Systems calculate the load ''average'' as the [[Moving average (technical analysis)#Exponential moving average | exponentially damped/weighted moving average]] of the load ''number''. The three values of load average refer to the past one, five, and fifteen minutes of system operation.

For single-CPU systems that are CPU-bound, one can think of load average as a percentage of system utilization during the respective time period. For systems with multiple CPUs, one must divide the number by the number of processors in order to get a comparable percentage.

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

* during the last minute, the CPU was overloaded by 73% (1 CPU with 1.73 runnable processes, so that 0.73 processes had to wait for a turn)
* during the last 5 minutes, the CPU was underloaded 50% (no processes had to wait for a turn)
* during the last 15 minutes, the CPU was overloaded 698% (1 CPU with 7.98 runnable processes, so that 6.98 processes had to wait for a turn)

This means that this CPU could have handled all of the work scheduled for the last minute if it were 1.73 times as fast, or if there were two (the [[Ceiling_function|ceiling]] of 1.73) times as many CPUs, but that over the last five minutes it was twice as fast as necessary to prevent runnable processes from waiting their turn.

In a system with four CPUs, a load average of 3.73 would indicate that there were, on average, 3.73 processes ready to run, and each one could be scheduled into a CPU.

On modern UNIX systems, the treatment of [[Thread (computer science)|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 [[Thread (computer science)#N:M|N:M 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.

Many systems generate the load average by sampling the state of the scheduler periodically, rather than recalculating on all pertinent scheduler events. They adopt this approach for performance reasons, as scheduler events occur frequently, and scheduler efficiency impacts significantly on system efficiency. As a result, sampling error can lead to load averages inaccurately representing actual system behavior. This can pose a particular problem for programs that wake up at a fixed interval that aligns with the load-average sampling, in which case a process may be under- or over-represented in the load average numbers.

@@ Line 1: / Line 1: @@
-All Unix and Unix-like systems generate a metric of three "load average" numbers in the kernel. Users can easily query the current result from a Unix shell by running the <tt>uptime</tt> command:
+All Unix and Unix-like systems generate a metric of three "load average" numbers in the kernel. Users can easily query the current result from a Unix shell by running the '''<tt>uptime</tt>''' command:
   $ uptime
 :53:15  up 119 days, 19:08,  10 users,  load average: 3.73 7.98 0.50
-The <tt>w</tt> and <tt>top</tt> commands show the same three load average numbers, as do a range of graphical user interface utilities.
+The '''<tt>w</tt>''' , '''<tt>prstat</tt>''' and '''<tt>top</tt>''' commands show the same three load average numbers, as do a range of graphical user interface utilities.
 An idle computer has a load number of 0 and each [[process (computing)|process]] using or waiting for [[Central processing unit|CPU]] adds to the load number by 1.  Most UNIX systems count only processes in the ''running'' (on CPU) or ''runnable'' (waiting for CPU) [[Process states | states]].  However, Linux also includes processes in [[uninterruptible sleep]] states (usually waiting for [[Hard disk|disk]] activity), which can lead to markedly different results if many processes remain blocked in [[Input/output|I/O]] due to a busy or stalled I/O system. This, for example, includes processes blocking due to an [[Network File System (protocol)|NFS]] server failure or to slow [[Data storage device|media]] (e.g., [[Universal Serial Bus|USB]] 1.x storage devices). Such circumstances can result in an elevated load average, which does not reflect an actual increase in CPU use (but still gives an idea on how long users have to wait).

@@ Line 6: / Line 6: @@
 The '''<tt>w</tt>''' , '''<tt>prstat</tt>''' and '''<tt>top</tt>''' commands show the same three load average numbers, as do a range of graphical user interface utilities.
-An idle computer has a load number of 0 and each [[process (computing)|process]] using or waiting for [[Central processing unit|CPU]] adds to the load number by 1.  Most UNIX systems count only processes in the ''running'' (on CPU) or ''runnable'' (waiting for CPU) [[Process states | states]].  However, Linux also includes processes in [[uninterruptible sleep]] states (usually waiting for [[Hard disk|disk]] activity), which can lead to markedly different results if many processes remain blocked in [[Input/output|I/O]] due to a busy or stalled I/O system. This, for example, includes processes blocking due to an [[Network File System (protocol)|NFS]] server failure or to slow [[Data storage device|media]] (e.g., [[Universal Serial Bus|USB]] 1.x storage devices). Such circumstances can result in an elevated load average, which does not reflect an actual increase in CPU use (but still gives an idea on how long users have to wait).
+An idle computer has a load number of 0 and each process using or waiting for CPU adds to the load number by 1.  Most UNIX systems count only processes in the ''running'' (on CPU) or ''runnable'' (waiting for CPU) states.  However, Linux also includes processes in uninterruptible sleep states (usually waiting for disk activity), 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 to 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 (but still gives an idea on how long users have to wait).
-Systems calculate the load ''average'' as the [[Moving average (technical analysis)#Exponential moving average | exponentially damped/weighted moving average]] of the load ''number''. The three values of load average refer to the past one, five, and fifteen minutes of system operation.
+Systems calculate the load ''average'' as the exponentially damped/weighted moving average of the load ''number''. The three values of load average refer to the past one, five, and fifteen minutes of system operation.
 For single-CPU systems that are CPU-bound, one can think of load average as a percentage of system utilization during the respective time period. For systems with multiple CPUs, one must divide the number by the number of processors in order to get a comparable percentage.
@@ Line 18: / Line 18: @@
 * during the last 15 minutes, the CPU was overloaded 698% (1 CPU with 7.98 runnable processes, so that 6.98 processes had to wait for a turn)
-This means that this CPU could have handled all of the work scheduled for the last minute if it were 1.73 times as fast, or if there were two (the [[Ceiling_function|ceiling]] of 1.73) times as many CPUs, but that over the last five minutes it was twice as fast as necessary to prevent runnable processes from waiting their turn.
+This means that this CPU could have handled all of the work scheduled for the last minute if it were 1.73 times as fast, or if there were two (the ceiling of 1.73) times as many CPUs, but that over the last five minutes it was twice as fast as necessary to prevent runnable processes from waiting their turn.
 In a system with four CPUs, a load average of 3.73 would indicate that there were, on average, 3.73 processes ready to run, and each one could be scheduled into a CPU.
-On modern UNIX systems, the treatment of [[Thread (computer science)|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 [[Thread (computer science)#N:M|N:M 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.
+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 N:M 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.
 Many systems generate the load average by sampling the state of the scheduler periodically, rather than recalculating on all pertinent scheduler events.  They adopt this approach for performance reasons, as scheduler events occur frequently, and scheduler efficiency impacts significantly on system efficiency.  As a result, sampling error can lead to load averages inaccurately representing actual system behavior.  This can pose a particular problem for programs that wake up at a fixed interval that aligns with the load-average sampling, in which case a process may be under- or over-represented in the load average numbers.