文章出处：http://blog.chinaunix.net/uid-12693781-id-368837.html
摘要：确定cpu的负载的定义，帮助管理员设置cpu负载阀值，推测可能的导致cpu负载过高的原因，进而保证服务器的正常运行。
1.cpu负载的定义
首先，看看cpu负载的定义。在一般情况下可以将单核心cpu的负载看成是一条单行的桥，数字1代表cpu刚好能够处理过来，即桥上能够顺利通过所有的车辆，
桥外没有等待的车辆，桥是畅通的。当超过1时表示有等待上桥的车辆，小于1时表示车辆能够快速的通过。单核心cpu就表示该cpu能够处理的事务数是1，在多核
cpu中cpu能够并行处理的事务的数量应该是cpu个数*cpu核数，而且负载数最好不要超过这个数值。例如一个4核cpu，则cpu_load最大值为4，不能长期超过4，否则会有任务没有得到及时的处理,而使系统的负载累积增高，导致系统运行缓慢。
大多数的Unix系统中的负载只是记录那些处在运行状态和可运行状态的进程，但是Linux有所不同，它会包含那些不可中断的处于睡眠状态的进程。这时当这些进程由于I/O的阻塞而不能够运行，就可能显著的增加cpu的负载。所以在Unix和Linux下的cpu的负载的计算方法是不一样的，在设定监测值的时候也需要特别考率。
下面从内核源码中分析cpu负载的计算根源，这里能够给出cpu负载的完整计算方法。下面的代码是是在kernel-2.6.32中的kernel/shed.c中截取的，用来计算cpu的平均负载。
/* Variables and functions for calc_load */
static atomic_long_t calc_load_tasks;
static unsigned long calc_load_update;
unsigned long avenrun[3];
EXPORT_SYMBOL(avenrun);
/**
* get_avenrun - get the load average array
* @loads: pointer to dest load array
* @offset: offset to add
* @shift: shift count to shift the result left
*
* These values are estimates at best, so no need for locking.
*/
void get_avenrun(unsigned long *loads, unsigned long offset, int shift)
{
loads[0] = (avenrun[0] + offset) << shift;
loads[1] = (avenrun[1] + offset) << shift;
loads[2] = (avenrun[2] + offset) << shift;
}
static unsigned long
calc_load(unsigned long load, unsigned long exp, unsigned long active)
{
load *= exp;
load += active * (FIXED_1 - exp);
return load >> FSHIFT;
}
/*
* calc_load - update the avenrun load estimates 10 ticks after the
* CPUs have updated calc_load_tasks.
*/
void calc_global_load(void)
{
unsigned long upd = calc_load_update + 10;
long active;
if (time_before(jiffies, upd))
return;
active = atomic_long_read(&calc_load_tasks);
active = active > 0 ? active * FIXED_1 : 0;
avenrun[0] = calc_load(avenrun[0], EXP_1, active);
avenrun[1] = calc_load(avenrun[1], EXP_5, active);
avenrun[2] = calc_load(avenrun[2], EXP_15, active);
calc_load_update += LOAD_FREQ;
}
/*
* Either called from update_cpu_load() or from a cpu going idle
*/
static void calc_load_account_active(struct rq *this_rq)
{
long nr_active, delta;
nr_active = this_rq->nr_running; //记录在cpu上运行的进程数
nr_active += (long) this_rq->nr_uninterruptible; //记录不可中断的进程数
if (nr_active != this_rq->calc_load_active) {
delta = nr_active - this_rq->calc_load_active;
this_rq->calc_load_active = nr_active;
atomic_long_add(delta, &calc_load_tasks);
}
}
从上面的代码特别是注释的两行可以看出，Linux记录cpu负载的时候是将cpu队列中的运行进程数和不可中断进程数都统计在内的，这样在对cpu负载分析的时候就需要考虑不可中断的进程的情况
2.影响cpu负载的进程
从定义可以看出cpu的负载主要来自在cpu运行的进程数，队列中准备就绪的进程数和不可中断进程数。那么当cpu负载过高的时候如果能够知道当前运行的进程的状态那么就能够判断是哪些进程的运行导致了问题。刚好，在Linux中ps可以帮助查找当前在运行的进程的状态，通过对这些进程的状态的了解，就能够很好的查找问题的真正原因。
＃ps aux可以显示进程的运行状态
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
当使用ps aux后就可以得知一个进程的11项参数，其中STAT是显示进程的运行状态。
进程的状态有以下几种。
=================进程STAT状态====================
D 无法中断的休眠状态（通常 IO 的进程）
R 正在运行，在可中断队列中；
S 处于休眠状态，静止状态；
T 停止或被追踪，暂停执行；
W 进入内存交换（从内核2.6开始无效）；
X 死掉的进程；
Z 僵尸进程不存在但暂时无法消除；
W: 没有足够的记忆体分页可分配
WCHAN 正在等待的进程资源；
<:高优先级进程
N: 低优先序进程
L: 有记忆体分页分配并锁在记忆体内 (即时系统或捱A I/O)，即,有些页被锁进内存
s 进程的领导者（在它之下有子进程）；
l 多进程的（使用 CLONE_THREAD, 类似 NPTL pthreads）；
+ 位于后台的进程组；
3.防止cpu负载过高的方法
短期来看，可以通过kill和killall来杀死一些影响cpu负载的进程，达到降低cpu负载的目的。
这些进程的状态是可以利用ps 显示出来的，然后对相关的进程采取一定的措施就能在短时间内降低cpu的负载。
关于kill和killall的用法，这里不做详细的介绍。
4.cpu负载过高的进一步分析
长远来看，要想cpu的负载不高，就要从cpu的利用率和当前的服务来进行分析。
下面以具体的案例进行分析：
我们有台服务器，当服务器的链接数过高时，就会导致nfs阻塞（该台服务器和另外一台服务采用nfs共享文件），这时wa为95.8%，负载马上就上升到180.
server1:~$ est
467 connections established
当服务器有大量的链接数时会发生nfs阻塞的问题：
root 2631 0.2 0.0 0 0 ? D Jul20 50:28 [nfsd]
root 2632 0.2 0.0 0 0 ? D Jul20 49:24 [nfsd]
root 2633 0.2 0.0 0 0 ? S Jul20 49:27 [nfsd]
root 2634 0.2 0.0 0 0 ? S Jul20 49:47 [nfsd]
root 2635 0.2 0.0 0 0 ? S Jul20 51:12 [nfsd]
root 2636 0.2 0.0 0 0 ? S Jul20 49:00 [nfsd]
root 2637 0.2 0.0 0 0 ? S Jul20 49:39 [nfsd]
root 2638 0.2 0.0 0 0 ? D Jul20 50:24 [nfsd]
server1:~$ top
top - 16:13:12 up 14 days, 21:21, 2 users, load average: 180.20, 59.85, 22.61
Tasks: 125 total, 1 running, 124 sleeping, 0 stopped, 0 zombie
Cpu : 2.3%us, 1.3%sy, 0.0%ni, 0.0%id, 95.8%wa, 0.0%hi, 0.5%si, 0.0%st
Mem: 2076212k total, 2028752k used, 47460k free, 1804k buffers
Swap: 2104472k total, 1089140k used, 1015332k free, 244076k cached
通过这种简单的分析，就基本上可以断定问题处在nfs处，需要调整文件共享的方式。
5.关于cpu负载和利用率的关系
大家可以参考另一篇写得很好的文章。
http://www.blogjava.net/cenwenchu/archive/2008/06/30/211712.html
SIP的第四期结束了，因为控制策略的丰富，早先的的压力测试结果已经无法反映在高并发和高压力下SIP的运行状况，因此需要重新作压力测试。跟在测试人员后面做了快一周的压力测试，压力测试的报告也正式出炉，本来也就算是告一段落，但第二天测试人员说要修改报告，由于这次作压力测试的同学是第一次作，有一个指标没有注意，因此需要修改几个测试结果。那个没有注意的指标就是load average，他和我一样开始只是注意了CPU，内存的使用状况，而没有太注意这个指标，这个指标与他们通常的限制（10左右）有差别。重新测试的结果由于这个指标被要求压低，最后的报告显然不如原来的好看。自己也没有深入过压力测试，但是觉得不搞明白对将来机器配置和扩容都会有影响，因此去问了DBA和SA，得到的结果相差很大，看来不得不自己去找找问题的根本所在了。
通过下面的几个部分的了解，可以一步一步的找出Load Average在压力测试中真正的作用。
CPU时间片
为了提高程序执行效率，大家在很多应用中都采用了多线程模式，这样可以将原来的序列化执行变为并行执行，任务的分解以及并行执行能够极大地提高程序的运行效率。但这都是代码级别的表现，而硬件是如何支持的呢？那就要靠CPU的时间片模式来说明这一切。程序的任何指令的执行往往都会要竞争CPU这个最宝贵的资源，不论你的程序分成了多少个线程去执行不同的任务，他们都必须排队等待获取这个资源来计算和处理命令。先看看单CPU的情况。下面两图描述了时间片模式和非时间片模式下的线程执行的情况：
图 1 非时间片线程执行情况
图 2 非时间片线程执行情况
在图一中可以看到，任何线程如果都排队等待CPU资源的获取，那么所谓的多线程就没有任何实际意义。图二中的CPU Manager只是我虚拟的一个角色，由它来分配和管理CPU的使用状况，此时多线程将会在运行过程中都有机会得到CPU资源，也真正实现了在单CPU的情况下实现多线程并行处理。
多CPU的情况只是单CPU的扩展，当所有的CPU都满负荷运作的时候，就会对每一个CPU采用时间片的方式来提高效率。
在Linux的内核处理过程中，每一个进程默认会有一个固定的时间片来执行命令（默认为1/100秒），这段时间内进程被分配到CPU，然后独占使用。如果使用完，同时未到时间片的规定时间，那么就主动放弃CPU的占用，如果到时间片尚未完成工作，那么CPU的使用权也会被收回，进程将会被中断挂起等待下一个时间片。
CPU利用率和Load Average的区别
压力测试不仅需要对业务场景的并发用户等压力参数作模拟，同时也需要在压力测试过程中随时关注机器的性能情况，来确保压力测试的有效性。当服务器长期处于一种超负荷的情况下运行，所能接收的压力并不是我们所认为的可接受的压力。就好比项目经理在给一个人估工作量的时候，每天都让这个人工作12个小时，那么所制定的项目计划就不是一个合理的计划，那个人迟早会垮掉，而影响整体的项目进度。
CPU利用率在过去常常被我们这些外行认为是判断机器是否已经到了满负荷的一个标准，看到50%-60%的使用率就认为机器就已经压到了临界了。CPU利用率，顾名思义就是对于CPU的使用状况，这是对一个时间段内CPU使用状况的统计，通过这个指标可以看出在某一个时间段内CPU被占用的情况，如果被占用时间很高，那么就需要考虑CPU是否已经处于超负荷运作，长期超负荷运作对于机器本身来说是一种损害，因此必须将CPU的利用率控制在一定的比例下，以保证机器的正常运作。
Load Average是CPU的Load，它所包含的信息不是CPU的使用率状况，而是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息，也就是CPU使用队列的长度的统计信息。为什么要统计这个信息，这个信息的对于压力测试的影响究竟是怎么样的，那就通过一个类比来解释CPU利用率和Load Average的区别以及对于压力测试的指导意义。
我们将CPU就类比为电话亭，每一个进程都是一个需要打电话的人。现在一共有4个电话亭（就好比我们的机器有4核），有10个人需要打电话。现在使用电话的规则是管理员会按照顺序给每一个人轮流分配1分钟的使用电话时间，如果使用者在1分钟内使用完毕，那么可以立刻将电话使用权返还给管理员，如果到了1分钟电话使用者还没有使用完毕，那么需要重新排队，等待再次分配使用。
图 3 电话使用场景
上图中对于使用电话的用户又作了一次分类，1min的代表这些使用者占用电话时间小于等于1min，2min表示使用者占用电话时间小于等于2min，以此类推。根据电话使用规则，1min的用户只需要得到一次分配即可完成通话，而其他两类用户需要排队两次到三次。
电话的利用率 = sum (active use cpu time)/period
每一个分配到电话的使用者使用电话时间的总和去除以统计的时间段。这里需要注意的是是使用电话的时间总和(sum(active use cpu time))，这与占用时间的总和(sum(occupy cpu time))是有区别的。（例如一个用户得到了一分钟的使用权，在10秒钟内打了电话，然后去查询号码本花了20秒钟，再用剩下的30秒打了另一个电话，那么占用了电话1分钟，实际只是使用了40秒）
电话的Average Load体现的是在某一统计时间段内，所有使用电话的人加上等待电话分配的人一个平均统计。
电话利用率的统计能够反映的是电话被使用的情况，当电话长期处于被使用而没有的到足够的时间休息间歇，那么对于电话硬件来说是一种超负荷的运作，需要调整使用频度。而电话Average Load却从另一个角度来展现对于电话使用状态的描述，Average Load越高说明对于电话资源的竞争越激烈，电话资源比较短缺。对于资源的申请和维护其实也是需要很大的成本，所以在这种高Average Load的情况下电话资源的长期“热竞争”也是对于硬件的一种损害。
低利用率的情况下是否会有高Load Average的情况产生呢？理解占有时间和使用时间就可以知道，当分配时间片以后，是否使用完全取决于使用者，因此完全可能出现低利用率高Load Average的情况。由此来看，仅仅从CPU的使用率来判断CPU是否处于一种超负荷的工作状态还是不够的，必须结合Load Average来全局的看CPU的使用情况和申请情况。
所以回过头来再看测试部对于Load Average的要求，在我们机器为8个CPU的情况下，控制在10 Load左右，也就是每一个CPU正在处理一个请求，同时还有2个在等待处理。看了看网上很多人的介绍一般来说Load简单的计算就是2* CPU个数减去1-2左右（这个只是网上看来的，未必是一个标准）。
补充几点：
1．对于CPU利用率和CPU Load Average的结果来判断性能问题。首先低CPU利用率不表明CPU不是瓶颈，竞争CPU的队列长期保持较长也是CPU超负荷的一种表现。对于应用来说可能会去花时间在I/O,Socket等方面，那么可以考虑是否后这些硬件的速度影响了整体的效率。
这里最好的样板范例就是我在测试中发现的一个现象：SIP当前在处理过程中，为了提高处理效率，将控制策略以及计数信息都放置在Memcached Cache里面，当我将Memcached Cache配置扩容一倍以后，CPU的利用率以及Load都有所下降，其实也就是在处理任务的过程中，等待Socket的返回对于CPU的竞争也产生了影响。
2．未来多CPU编程的重要性。现在服务器的CPU都是多CPU了，我们的服务器处理能力已经不再按照摩尔定律来发展。就我上面提到的电话亭场景来看，对于三种不同时间需求的用户来说，采用不同的分配顺序，我们可看到的Load Average就会有不同。假设我们统计Load的时间段为2分钟，如果将电话分配的顺序按照：1min的用户，2min的用户，3min的用户来分配，那么我们的Load Average将会最低，采用其他顺序将会有不同的结果。所以未来的多CPU编程可以更好的提高CPU的利用率，让程序跑的更快。
以上所提到的内容未必都是很准确或者正确，如果有任何的偏差也请大家指出，可以纠正一些不清楚的概念。
