top
top是一个动态显示过程,即可以通过用户按键来不断刷新当前状态.如果在前台执行该命令,它将独占前台,直到用户终止该程序为止.比较准确的说,top命令提供了实时的对系统处理器的状态监视.它将显示系统中CPU最“敏感”的任务列表.该命令可以按CPU使用.内存使用和执行时间对任务进行排序；而且该命令的很多特性都可以通过交互式命令或者在个人定制文件中进行设定.
1．命令格式：
top [参数]
2．命令功能：
显示当前系统正在执行的进程的相关信息，包括进程ID、内存占用率、CPU占用率等
3．命令参数：
-b 批处理
-c 显示完整的治命令
-I 忽略失效过程
-s 保密模式
-S 累积模式
-i<时间> 设置间隔时间
-u<用户名> 指定用户名
-p<进程号> 指定进程
-n<次数> 循环显示的次数
4．使用实例：
实例1：显示进程信息
命令：top
输出：
[root@TG1704 log]# top
top - 14:06:23 up 70 days, 16:44, 2 users, load average: 1.25, 1.32, 1.35
Tasks: 206 total, 1 running, 205 sleeping, 0 stopped, 0 zombie
Cpu(s): 5.9%us, 3.4%sy, 0.0%ni, 90.4%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st
Mem: 32949016k total, 14411180k used, 18537836k free, 169884k buffers
Swap: 32764556k total, 0k used, 32764556k free, 3612636k cached</p>< p>PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
28894 root 22 0 1501m 405m 10m S 52.2 1.3 2534:16 java
18249 root 18 0 3201m 1.9g 11m S 35.9 6.0 569:39.41 java
2808 root 25 0 3333m 1.0g 11m S 24.3 3.1 526:51.85 java
25668 root 23 0 3180m 704m 11m S 14.0 2.2 360:44.53 java
574 root 25 0 3168m 611m 10m S 12.6 1.9 556:59.63 java
1599 root 20 0 3237m 1.9g 11m S 12.3 6.2 262:01.14 java
1008 root 21 0 3147m 842m 10m S 0.3 2.6 4:31.08 java
13823 root 23 0 3031m 2.1g 10m S 0.3 6.8 176:57.34 java
28218 root 15 0 12760 1168 808 R 0.3 0.0 0:01.43 top
29062 root 20 0 1241m 227m 10m S 0.3 0.7 2:07.32 java
1 root 15 0 10368 684 572 S 0.0 0.0 1:30.85 init
2 root RT -5 0 0 0 S 0.0 0.0 0:01.01 migration/0
3 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0
4 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
5 root RT -5 0 0 0 S 0.0 0.0 0:00.80 migration/1
6 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/1
7 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/1
8 root RT -5 0 0 0 S 0.0 0.0 0:20.59 migration/2
9 root 34 19 0 0 0 S 0.0 0.0 0:00.09 ksoftirqd/2
10 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/2
11 root RT -5 0 0 0 S 0.0 0.0 0:23.66 migration/3
12 root 34 19 0 0 0 S 0.0 0.0 0:00.03 ksoftirqd/3
13 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/3
14 root RT -5 0 0 0 S 0.0 0.0 0:20.29 migration/4
15 root 34 19 0 0 0 S 0.0 0.0 0:00.07 ksoftirqd/4
16 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/4
17 root RT -5 0 0 0 S 0.0 0.0 0:23.07 migration/5
18 root 34 19 0 0 0 S 0.0 0.0 0:00.07 ksoftirqd/5
19 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/5
20 root RT -5 0 0 0 S 0.0 0.0 0:17.16 migration/6
21 root 34 19 0 0 0 S 0.0 0.0 0:00.05 ksoftirqd/6
22 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/6
23 root RT -5 0 0 0 S 0.0 0.0 0:58.28 migration/7
top命令输出内容详细说明：
统计信息区：
前五行是当前系统情况整体的统计信息区。下面我们看每一行信息的具体意义。
第一行，任务队列信息，同 uptime 命令的执行结果，具体参数说明情况如下：
14:06:23 — 当前系统时间
up 70 days, 16:44 — 系统已经运行了70天16小时44分钟（在这期间系统没有重启过的吆！）
2 users — 当前有2个用户登录系统
load average: 1.15, 1.42, 1.44 — load average后面的三个数分别是1分钟、5分钟、15分钟的负载情况。
load average数据是每隔5秒钟检查一次活跃的进程数，然后按特定算法计算出的数值。如果这个数除以逻辑CPU的数量，结果高于5的时候就表明系统在超负荷运转了。
第二行，Tasks — 任务（进程），具体信息说明如下：
系统现在共有206个进程，其中处于运行中的有1个，205个在休眠（sleep），stoped状态的有0个，zombie状态（僵尸）的有0个。
第三行，cpu状态信息，具体属性说明如下：
5.9%us — 用户空间占用CPU的百分比。
3.4% sy — 内核空间占用CPU的百分比。
0.0% ni — 改变过优先级的进程占用CPU的百分比
90.4% id — 空闲CPU百分比
0.0% wa — IO等待占用CPU的百分比
0.0% hi — 硬中断（Hardware IRQ）占用CPU的百分比
0.2% si — 软中断（Software Interrupts）占用CPU的百分比
备注：在这里CPU的使用比率和windows概念不同，需要理解linux系统用户空间和内核空间的相关知识！
第四行,内存状态，具体信息如下：
32949016k total — 物理内存总量（32GB）
14411180k used — 使用中的内存总量（14GB）
18537836k free — 空闲内存总量（18GB）
169884k buffers — 缓存的内存量 （169M）
第五行，swap交换分区信息，具体信息说明如下：
32764556k total — 交换区总量（32GB）
0k used — 使用的交换区总量（0K）
32764556k free — 空闲交换区总量（32GB）
3612636k cached — 缓冲的交换区总量（3.6GB）
备注：
第四行中使用中的内存总量（used）指的是现在系统内核控制的内存数，空闲内存总量（free）是内核还未纳入其管控范围的数量。纳入内核管理的内存不见得都在使用中，还包括过去使用过的现在可以被重复利用的内存，内核并不把这些可被重新使用的内存交还到free中去，因此在linux上free内存会越来越少，但不用为此担心。
如果出于习惯去计算可用内存数，这里有个近似的计算公式：第四行的free + 第四行的buffers + 第五行的cached，按这个公式此台服务器的可用内存：18537836k +169884k +3612636k = 22GB左右。
对于内存监控，在top里我们要时刻监控第五行swap交换分区的used，如果这个数值在不断的变化，说明内核在不断进行内存和swap的数据交换，这是真正的内存不够用了。
第六行，空行。
第七行以下：各进程（任务）的状态监控，项目列信息说明如下：
PID — 进程id
USER — 进程所有者
PR — 进程优先级
NI — nice值。负值表示高优先级，正值表示低优先级
VIRT — 进程使用的虚拟内存总量，单位kb。VIRT=SWAP+RES
RES — 进程使用的、未被换出的物理内存大小，单位kb。RES=CODE+DATA
SHR — 共享内存大小，单位kb
S — 进程状态。D=不可中断的睡眠状态 R=运行 S=睡眠 T=跟踪/停止 Z=僵尸进程
%CPU — 上次更新到现在的CPU时间占用百分比
%MEM — 进程使用的物理内存百分比
TIME+ — 进程使用的CPU时间总计，单位1/100秒
COMMAND — 进程名称（命令名/命令行）
其他使用技巧：
1.多U多核CPU监控
在top基本视图中，按键盘数字“1”，可监控每个逻辑CPU的状况：
观察上图，服务器有16个逻辑CPU，实际上是4个物理CPU。再按数字键1，就会返回到top基本视图界面。
2.高亮显示当前运行进程
敲击键盘“b”（打开/关闭加亮效果），top的视图变化如下：
我们发现进程id为2570的“top”进程被加亮了，top进程就是视图第二行显示的唯一的运行态（runing）的那个进程，可以通过敲击“y”键关闭或打开运行态进程的加亮效果。
3.进程字段排序
默认进入top时，各进程是按照CPU的占用量来排序的，在下图中进程ID为28894的java进程排在第一（cpu占用142%），进程ID为574的java进程排在第二（cpu占用16%）。
敲击键盘“x”（打开/关闭排序列的加亮效果），top的视图变化如下：
可以看到，top默认的排序列是“%CPU”。
4. 通过”shift + >”或”shift + <”可以向右或左改变排序列
下图是按一次”shift + >”的效果图,视图现在已经按照%MEM来排序。
实例2：显示 完整命令
命令：top -c
输出：
实例3：以批处理模式显示程序信息
命令：top -b
实例4：以累积模式显示程序信息
命令：top -S
实例5：设置信息更新次数
命令：top -n 2
说明：表示更新两次后终止更新显示
实例6：设置信息更新时间
命令：top -d 3
说明：表示更新周期为3秒
实例7：显示指定的进程信息
命令：top -p 574
输出：
5.top交互命令
在top 命令执行过程中可以使用的一些交互命令。这些命令都是单字母的，如果在命令行中使用了s 选项， 其中一些命令可能会被屏蔽。
h 显示帮助画面，给出一些简短的命令总结说明
k 终止一个进程。
i 忽略闲置和僵死进程。这是一个开关式命令。
q 退出程序
r 重新安排一个进程的优先级别
S 切换到累计模式
s 改变两次刷新之间的延迟时间（单位为s），如果有小数，就换算成m s。输入0值则系统将不断刷新，默认值是5 s
f或者F 从当前显示中添加或者删除项目
o或者O 改变显示项目的顺序
l 切换显示平均负载和启动时间信息
m 切换显示内存信息
t 切换显示进程和CPU状态信息
c 切换显示命令名称和完整命令行
M 根据驻留内存大小进行排序
P 根据CPU使用百分比大小进行排序
T 根据时间/累计时间进行排序
W 将当前设置写入~/.toprc文件中
Load Average
几乎每个接触类 Unix 操作系统的工程师都知道如何查看系统负载。但这东西的工作机理到底是怎样的，可能没有多少能说清楚。对比了一些相关信息，加上自己的理解，做一下笔记。
什么是 Load ? 什么是 Load Average ?
Load 就是对计算机干活多少的度量(WikiPedia: the system load is a measure of the amount of work that a computer system is doing)。也有简单的说是进程队列的长度. Load Average 就是一段时间 (1 分钟、5分钟、15分钟) 内平均 Load 。【最好的参考文章：UNIX® Load Average Part 1: How It Works】
下面是一个 uptime 命令输出：
$ uptime 18:57:48 up 423 days, 3:55, 2 users, load average: 1.16, 1.12, 1.20
尽管各种信息来源的定义都不太确定。能确定的一件事情是，你不能精确获取当前时间的 Load . 最小的计算粒度是 5 秒钟(CALC_LOAD 每 5HZ 计算一次, 5HZ 为 5秒钟，这里的 HZ 是系统定义的变量). 参见 Linux Kernel 这段代码:
869 count -= ticks;
870 if (unlikely(count < 0)) {
871 active_tasks = count_active_tasks();
872 do {
873 CALC_LOAD(avenrun[0], EXP_1, active_tasks);
874 CALC_LOAD(avenrun[1], EXP_5, active_tasks);
875 CALC_LOAD(avenrun[2], EXP_15, active_tasks);
876 count += LOAD_FREQ;
877 } while (count < 0);
878 }
879}
如何判断系统是否已经 Over Load ?
对一般的系统来说，根据 CPU 数量去判断，如上面的例子， 如果平均负载始终在 1.2 以下，而你是 2 颗 CPU 的机器。那么基本不会出现 CPU 不够用的情况。也就是 Load 平均要小于 CPU 的数量。
这是 Solaris 性能与工具(Solaris Performance Tools ) 一书推荐的评估方法。【在这里要推荐一下这本书，尽管在 Load 这个地方没有达到我期望的那么细致。但全书揭示了非常多的性能信息。每个DBA、架构师 的必须书。】
这么说实际上带来另外两个疑问：
1 如果是多核 CPU / 超线程的机器怎么判断? 对这样的机器，我的建议是看操作系统怎么识别的 CPU，根据系统识别出来的逻辑 CPU 数量来判断。如果要考虑性能系数，建议参考一下 Oracle 针对不同架构下多核 CPU 的收费标准。
2 如果应用是面向线程的怎么判断? 这实际上和 M:N 线程模型有关。你的系统是怎样的? 把这个问题考虑进去即可了。
多数情况下，Load 过高都未必和 CPU 有关。或许倒是有一个例外的，就是应用场景的问题。比如用单 CPU 的机器去做高并发 Web 服务器，麻烦就来了
Load 与容量规划(Capacity Planning)
任何一个相对成熟的站点都会利用 Cacti（基于RRDTool） 等工具进行容量规划工作。抓取的 Load 会传 1、5、15 分钟列值过去，这三个度量采用哪个呢? 15 分钟为首选【参见Gunther 的 PPT】。
Load 与系统预警
很多对可用性要求比较高的环境都建立了 邮件或SMS 报警机制。关于 Load 报警阈值的制定也有看到不太合理的时候。这里建议 Critical 值(如果用 Nagios 之类的工具你明白这是什么)上限为 物理 CPU 的个数(当然你可以设置比这个低)。但比这个值高的话，意义就不大了。比如，数据库服务器有 4 颗 CPU，那么 Load 高于 4 就应该报警出来，设置比 4 高可能意义不大，因为接到报警还有个人为响应时间...
误解 一：系统 Load 高一定是性能有问题。
真相：系统 Load 高也或许是因为在进行 CPU 密集型的计算(比如编译)
误解 二：系统 Load 高一定是 CPU 能力问题或数量不够。
真相：Load 高只是代表需要运行的队列累积过多了。但队列中的任务实际可能是耗 CPU的，也可能是耗 I/O 乃至其它因素的。
误解 三：系统长期 Load 高，首选增加 CPU。
真相：Load 只是表象，不是实质。增加 CPU 个别时候会临时看到系统 Load 下降，但治标不治本。
小小一个 Load 讲究其实不少。英文信息其实比较全的，尽量保证加入一点新信息到这篇文章里。入看到有写的不合理的地方或者有异议，请指正或告知。
--EOF--
FAQ 1：数据库服务器突然 CPU 100% 繁忙，咋办?
A ：一般情况下，这是由糟糕的 SQL 引起。建议抓取 Slow Query Log ，针对 I/O 开销比较大(重点看全表扫描）的 SQL 进行优化。根据经验值，每个 CPU Core 一秒钟能处理 100-400MB 数据量。如果是大量的并发 I/O 操作，尽管存储的吞吐可能还没那么大，也可能会把 CPU "塞满"。
负载分析
运维工程师在日常运维中经常使用 w 、 top 、 uptime 等命令来查看系统当前运行的负载情况。那么作为运维工程师是如何通过以上命令来判断系统当前负载是否已经达到极限了呢？为此笔者总结了一下如何通过 loadaverage 返回的数据来判断系统运行情况。什么是Load？什么是Load Average?
Load用最通俗的语言说就是当前cpu需要干的工作量的多少。简单的说是进程队列的长度。
Load Average 就是一段时间（1分钟、5分钟、15分钟）内平均负载。
top - 10:02:01 up 180 days, 19:34, 2 users,
load average: 2.77, 2.91, 2.72
以上数据代表1分钟，5分钟，15分钟内的CPU的平均负载。
如果系统cpu超负荷 load average会大于您机器的cpu数量，比如您机器2颗物理cpu在每颗物理cpu上又做了6颗逻辑CPU之后在每颗逻辑CPU上又实现了超线程后，假如此时你在系统中使用cat /proc/cpuinfo |grep 'processor'|wc –l返回24颗，如果load值（15分钟的返回值作为参考依据）长期在24以上，说明系统已经很繁忙了。
当然load值走高也不一定就是cpu资源紧张导致的，我们还需要结合vmstat工具进行确认和判断是cpu不足还是磁盘IO问题又或者是内存不足导致。
那么在Load average 高的情况下如何确定系统瓶颈呢？下面我就需要借助vmstat工具做进一步分析了。
[root@localhost ~]# vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 256968 42428 159696 659584 0 0 0 0 0 0 1 0 99 0 0
1 0 256968 42304 159696 659584 0 0 0 0 20689 31827 1 1 98 0 0
一、procs列
r 列表示运行和等待cpu时间片的进程数，如果长期大于1，说明cpu不足，需要增加cpu。
b 列表示在等待资源的进程数，比如正在等待I/O、或者内存交换等。
wa 列显示了IO等待所占用的CPU时间的百分比。这里wa的参考值为30%，如果wa超过30%，说明IO等待严重，这可能是磁盘大量随机访问造成的，也可能磁盘或者磁盘访问控制器的带宽瓶颈造成的(主要是块操作)。
id 列显示了cpu处在空闲状态的时间百分比
二、system 显示采集间隔内发生的中断数
in 列表示在某一时间间隔中观测到的每秒设备中断数。
cs列表示每秒产生的上下文切换次数，如当 cs 比磁盘 I/O 和网络信息包速率高得多，都应进行进一步调查。
三、memory列
memory
swpd 切换到内存交换区的内存数量(k表示)。如果swpd的值不为0，或者比较大，比如超过了100m，只要si、so的值长期为0，系统性能还是正常
free 当前的空闲页面列表中内存数量(k表示)
buff 作为buffer cache的内存数量，一般对块设备的读写才需要缓冲。
cache: 作为page cache的内存数量，一般作为文件系统的cache，如果cache较大，说明用到cache的文件较多，如果此时IO中bi比较小，说明文件系统效率比较好。
四、swap列
si 由内存进入内存交换区数量。
so由内存交换区进入内存数量。
四、IO列
bi 从块设备读入数据的总量（读磁盘）（每秒kb）。
bo 块设备写入数据的总量（写磁盘）（每秒kb）
这里我们设置的bi+bo参考值为1000，如果超过1000，而且wa值较大应该考虑均衡磁盘负载，可以结合iostat输出来分析。
五、cpu列
cpu 表示cpu的使用状态
us 列显示了用户方式下所花费 CPU 时间的百分比。us的值比较高时，说明用户进程消耗的cpu时间多，但是如果长期大于50%，需要考虑优化用户的程序。
sy 列显示了内核进程所花费的cpu时间的百分比。这里us + sy的参考值为80%，如果us+sy 大于 80%说明可能存在CPU不足。
查看磁盘负载iostat
每隔2秒统计一次磁盘IO信息，直到按Ctrl+C终止程序，-d 选项表示统计磁盘信息， -k 表示以每秒KB的形式显示，-t 要求打印出时间信息，2 表示每隔 2 秒输出一次。第一次输出的磁盘IO负载状况提供了关于自从系统启动以来的统计信息。随后的每一次输出则是每个间隔之间的平均IO负载状况。
[root@localhost ~]# iostat -x 1 10
avg-cpu: %user %nice %system %iowait %steal %idle
0.33 0.00 0.08 0.04 0.00 99.55
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 17.00 0.00 4.00 0.00 168.00 42.00 0.02 4.00 3.00 1.20
如果 %util 长期接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。Idle如果长期大于70% IO压力就比较大了,这时一般读取速度有较多的wait.
理解load average
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的利用率，让程序跑的更快。
以上所提到的内容未必都是很准确或者正确，如果有任何的偏差也请大家指出，可以纠正一些不清楚的概念。