Chinaunix首页 | 论坛 | 博客
  • 博客访问: 717175
  • 博文数量: 126
  • 博客积分: 2944
  • 博客等级: 上校
  • 技术积分: 1160
  • 用 户 组: 普通用户
  • 注册时间: 2005-02-17 11:09
个人简介

文章分类

全部博文(126)

文章存档

2022年(1)

2018年(1)

2017年(5)

2016年(5)

2013年(5)

2012年(21)

2011年(24)

2010年(1)

2009年(2)

2008年(12)

2007年(6)

2006年(19)

2005年(24)

分类: LINUX

2011-09-21 08:55:03

From 

In UNIX computing, the system load is a measure of the amount of 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.

Contents [hide]
[edit]Unix-style load calculation

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 uptime command:

$ uptime 14:34:03 up 10:43, 4 users, load average: 0.06, 0.11, 0.09

The w and top commands show the same three load average numbers, as do a range of graphical user interface utilities. In Linux, they can also be accessed by reading the /proc/loadavg file.

An idle computer has a load number of 0 and each process using or waiting for CPU (the ready queue or run queue) increments the load number by 1. Most UNIX systems count only processes in therunning (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 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 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 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.

[edit]CPU load vs CPU utilization

A comparative study of different load indices carried out by Ferrari et al.[1] 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, will probably have utilizations close to 100% although they obviously differ.

[edit]CPU Load Computation

On Linux systems, the load-average is not calculated on each clock tick, but driven by a variable value that is based on the HZ frequency setting and tested on each clock tick. (HZ variable is the pulse rate of particular Linux kernel activity. 1HZ is equal to one clock tick; 10ms by default.) Although the HZ value can be configured in some versions of the kernel, it is normally set to 100. The calculation code uses the HZ value to determine the CPU Load calculation frequency. Specifically, the timer.c::calc_load() function will run the algorithm every 5 * HZ, or roughly every five seconds. Following is that function in its entirety:

unsigned long avenrun[3]; 
static inline void calc_load(unsigned long ticks) { 
  unsigned long active_tasks; /* fixed-point */ 
  static int count = LOAD_FREQ; 
  count -= ticks; 
  if (count < 0) { 
    count += LOAD_FREQ; 
    active_tasks = count_active_tasks(); 
    CALC_LOAD(avenrun[0], EXP_1, active_tasks); 
    CALC_LOAD(avenrun[1], EXP_5, active_tasks); 
    CALC_LOAD(avenrun[2], EXP_15, active_tasks);
  }
}

The avenrun array contains 1-minute, 5-minute and 15-minute average. The CALC_LOAD macro and its associated values are defined in sched.h :

#define FSHIFT 11 /* nr of bits of precision */ 
#define FIXED_1 (1< 
#define LOAD_FREQ (5*HZ) /* 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) */ 
#define CALC_LOAD(load,exp,n) \ 
 load *= exp; \
 load += n*(FIXED_1-exp); \
 load >>= FSHIFT;
[edit]Other system performance commands

Other commands for assessing system performance include:

  • uptime the system reliability and load average
  • top for an overall system view
  • htop interactive process viewer
  • iotop interactive I/O viewer - iotop homepage
  • iostat for storage I/O statistics
  • netstat for network statistics
  • mpstat for CPU statistics
  • tload load average graph for terminal
  • xload load average graph for X
[edit]See also[edit]External links[edit]Notes
  1. ^ This paper's discussion is useful, but it contains at least one error, in equation 3 (Section 4.2, page 12): The equation should be load(t) = n e-5/60 + load(t-1) (1 - e-5/60) instead of load(t) = load(t-1) e-5/60 + n (1 - e-5/60).
[edit]References
  1. ^ Domenico Ferrari and Songnian Zhou, “An Empirical Investigation of Load Indices For Load Balancing Applications” Proc. Performance ’87, the 12th Int’l Symp. On Computer Performance Modeling, Measurement, and Evaluation, North Holland Publishers, Amsterdam. The Netherlands 1988. pp. 515-528
阅读(1498) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~