在对系统的方法化分析中，首要且最基本的工具之一常常是对系统的 CPU利用率进行简单测量。 Linux以及大多数基于 UNIX的操作系统都提供了一条命令来显示系统的平均负荷(loadaverage) 。
[huangc@V-02-01-00860 ~]$ uptime
11:18:05 up 78 days, 1:17, 11 users, load average: 0.20, 0.13, 0.12具体地讲，平均负荷值代表了在 1min、 5min和 15min内可以运行的任务平均数量。可运行的任务包括当前正在运行的任务以及虽然可以运行但正在等待某个处理器空闲的任务。本例中的系统只有两个 CPU，它可以通过查看/proc/cpuinfo的内容来确定
[huangc@V-02-01-00860 ~]$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz
stepping : 4
cpu MHz : 2500.000
cache size : 25600 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology tsc_reliable nonstop_tsc aperfmperf unfair_spinlock pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt aes xsave avx f16c rdrand hypervisor lahf_lm ida arat xsaveopt pln pts dts fsgsbase smep
bogomips : 5000.00
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz
stepping : 4
cpu MHz : 2500.000
cache size : 25600 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology tsc_reliable nonstop_tsc aperfmperf unfair_spinlock pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt aes xsave avx f16c rdrand hypervisor lahf_lm ida arat xsaveopt pln pts dts fsgsbase smep
bogomips : 5000.00
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:在本例中，对于两个处理器存在两项，因此平均情况下，处理器要执行的工作会稍少于它的处理能力。在较高层次上，这意味着机器需要执行的工作少于它的处理能力。注意：若在双 CPU的机器上 uptime命令显示的负荷平均值小于 2.00的话，这表明处理器仍拥有额外的空闲周期。在 4个 CPU的机器上如果负荷平均值小于 4.00的话也表明同样的情况，如此等等。然而，负荷平均值单独并不能说明全部问题。
尽管该工具可以检测CPU获得了利用情况， 但它并不指明系统正在执行什么工作以及如此繁忙的原因。如果该系统的用户响应时间是可接受的，可能没有任何理由需要更深入地探究系统的运行情况。
诸如uptime之类的简单工具常常是用户试图对应用各种可觉察的缓慢响应时间加以解释的快捷方式。若系统的平均负荷值表明响应时间可能是由单个(或多个)过载的处理器所引起的，那么可以使用许多其他工具来缩小负荷起因的范围。
为了更深入地探究处理器的使用情况，下面介绍的 3种工具可以提供许多关于CPU利用情况的不同理解： vmstat、 iostat和 top。 这些工具各自关注系统监视的不同方面，但都可获得关于处理器当前使用情况的不同视图。特别地，下一个步骤是理解处理器是否将处理时间主要消耗在操作系统(经常称为内核空间)或应用(经常称为用户空间)之中，或者处理器是否处于空闲状态。如果处理器处于空闲状态，则理解其空闲的原因是所有进一步性能分析的关键。有许多原因可以导致处理器空闲。例如，最明显的原因是某个进程无法运行。 这听起来或许过于明显， 但如果工作负荷的某个组件(例如特定进程或任务)没有正在运行的话，则性能可能受到影响。在某些情况下，对组件实施缓存或后退(fallback)机制可以允许一些应用继续运行， 尽管吞吐率会降低。 例如， Internet域名服务经常被配置为对 named守护进程或者 off-host服务进行查询。如果某个域名服务提供商(例如出现在/etc/resolv.conf的第一行 name server语句中)当前没有运行，则在查询其他信息提供商之前可能存在一个超时周期。对于用户来说，这可能看起来像是应用中的不定时延迟。对于使用 uptime来监视系统的用户来说，平均负荷值看起来可能不是很高。然而，在这种情况下，vmstat的输出可以有助于缩小排查问题的范围。
一、vmstat vmstat是一个实时性能监视工具。该工具提供了有助于发现系统异常活动的数据，例如会降低系统性能的过多页面错误或上下文切换次数。这些数据的显示频率可由用户指定。vmstat输出样本如下所示：
[huangc@V-02-01-00860 ~]$ vmstat
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 3853948 1386860 43092 5049692 1 6 5 34 1 3 27 27 46 0 0 vmstat
提供以下信息 ：
- procs部分提供了在生成报告时正在运行的进程数目(r)以及被阻塞的进程数目(b)。可以利用这些信息来检查运行中以及阻塞进程的数目是否与预期值相符。如果与预期不符的话，可以检查：应用和内核的参数、系统调度器和 I/O调度器、进程在可用处理器之间的分布等。
- memory部分提供了换出内存(swpd)、空闲内存(free)、 I/O数据结构的缓冲区缓存(buff)，以及从磁盘读取文件的内存缓存(cache)的容量，单位为 KB。 swpd的取值反映了kswapd的活动情况 。
- s wap 部分提供了从磁盘上换入的内存容量 (si) 以及换出到磁盘上的内存量 (so) ， 单位为 KB/s 。 so 反映了当数据被换出至交换区时 kswapd 的活动情况，而 si 则反映了当页面被换回到物理内存时发生页面错误的情况 。
- io 部分提供了从设备读入的块数 (bi) 以及写出到设备上的块数 (bo) ，单位为 KB/s 。当运行 I/O 密集的应用时，应特别注意这两个部分的值 。
- system 部分提供了每秒的中断数目 (in) 和上下文切换数目 (cs) 。
- cpu 部分提供了用户 (us) 、 系统 (sy) 、 真正空闲 (id) 以及等待 I/O 完成 (wa) 在 CPU 总时间中所占的百分比。 CPU 利用率也许是最常用的量度。 若 wa 值过大， 则应该检查 I/O 子系统，例如，可以断定需要更多的 I/O 控制器和磁盘以便减少 I/O 等待时间。
注意
uptime
提供了可运行进程数目在
3
个时间范围
(1min
、
5min
和
15min)
内的另一种视图。 因此， 如果
uptime
给出的平均负荷值在任何时间范围内都大于
1
，则
vmstat
报告的可运行任务数量也应该接近
1 。
vmstat
能够以重复的时间间隔定期提供信息，因此可通过以下命令获得动态的系统视图 。
vmstat 5 10 上述命令的含义是每
5s
输出
vmstat
信息， 共执行
10
次。 另外， 若根据
uptime
的输出结果， 平均负荷值在过去的
1/5/10min
内一直为
1
， 则该命令的输出结果通常应该在每个输出行均显示一项可运行的任务。 在
vmstat
的输出信息中出现峰值为
5
、
7
甚至
20
的情况并不奇怪。因为负荷平均值是一种计算平均值而不是即时快照。这两个视图对于系统性能分析工作而言各自有其优点 。
假设在一个场景中用户报告某个工作负荷的响应时间缓慢。 通过
uptime
检查负荷平均值的结果表明， 负荷平均值非常低， 甚至可能位于时间基线以下。 另外，
vmstat
显示出可运行任务的数量非常低， 且基于
CPU
空闲时间的百分比可判断该系统相对空闲。分析人员可能会将这些结果解释成某个关键进程已退出或正在阻塞等待某个未完成的事件。例如，一些应用程序使用某种信号量技术来分派工作并等待完成。也许工作被分派给一个后端服务器或其他应用程序，而该应用程序由于某种原因已停止处理所有活动。结果，与用户最接近的应用程序被阻塞，变为不可运行，并等待着反馈某个完成消息，然后它才能将信息返回给用户。这可能导致系统管理员将注意力集中于服务器应用以查明为何无法完成针对其排队的请求 。 在
另一个场景中，假定负荷平均值超过
1
，甚至可能比已建立的基线平均高出一个百分点。另外，
vmstat
显示总有一两个进程是可运行的，但在一段扩展的时间范围内用户时间的百分比将近
100%
。可能需要其他工具例如
ps(1)
或
top(1)
来发现有哪个或哪些进程正在占用着
100%
的
CPU
时间。
ps(1)
提供了所有当前存在的进程列表， 或基于命令选项给出选定的进程子集。
top(1)(
或
gtop(1))
为最活跃的进程提供了持续更新的视图， 其中最活跃的进程可定义为当前占用
CPU
时间最多的进程。这些数据可能有助于识别出在系统中没有执行有效工作的失控进程。 如果
vmstat(1)已报告这些进程主要在用户空间中运行，则系统管理员可能希望将调试器(例如 gdb(1))
连接至该进程，并使用断点、跟踪执行或其他调试方法来理解该应用当前执行的工作。 如果
vmstat已报告大部分时间都作为“ 系统” 时间而消耗，则可以使用其他工具例如 strace(1)
来确定正在执行哪些系统调用； 若
vmstat(1)报告指出相当大比例的时间都用于等待 I/O操作完成， 则可以使用 sar(1)
等工具来查看正在使用中的设备，并可能提供一些诸如哪些应用或文件系统处于使用中、系统是否正在执行交换或页面调度等信息 。
二、top与gtop工具
t
op
和
gtop
工具非常有助于对导致生成
vmstat
或
uptime
所显示的高层信息的任务和进程加以理解。
它们可以显示哪些进程是活跃的以及哪些进程消耗的处理时间或内存最多。
top
命令对于所有正在运行的进程和系统载荷提供不断更新的概览信息，包括
CPU
负荷、 内存使用以及每个进程的内存使用情况，具体如下面的快照内容所述。注意
top
也提供了负荷平均值的快照，这非常类似于
uptime(1)
的做法；然而，
top
也提供了关于被创建但当前正在休眠的进程数量以及正在运行的进程数量的分类汇总信息。“ 休眠”任务是那些处于被阻塞并等待某项活动的任务， 例如用户对键盘的一次按键、来自管道或
socket
的数据、来自另一台主机
(
例如，等待别人发出内容请求的
Web
服务器
)
的请求等。
top(1)
还单独显示了每个处理器的负荷平均值， 这有助于识别在调度任务过程中的任何不均衡性。默认状态下，
top
的输出被经常地刷新，且把任务基于
CPU
占用时间的百分比排序。当然也可能存在着其他排序选项，例如
CPU
累加消耗量或者内存消耗百分比 。
[huangc@V-02-01-00860 ~]$ top
top - 15:17:44 up 78 days, 5:17, 13 users, load average: 0.00, 0.10, 0.12
Tasks: 227 total, 1 running, 225 sleeping, 1 stopped, 0 zombie
Cpu(s): 7.8%us, 12.1%sy, 0.0%ni, 79.9%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st
Mem: 8193720k total, 6315000k used, 1878720k free, 47436k buffers
Swap: 4128760k total, 3852496k used, 276264k free, 5054928k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2301 seeproxy 20 0 2196m 13m 660 S 15.5 0.2 15285:39 /home/seeproxy/seeproxy/python27/bin/python /home/seeproxy/seeproxy/seeproxy.p
30824 huangc 20 0 872m 1744 1096 S 7.3 0.0 64:05.38 hsserver -f warmstandby_hc.xml -start proxysvr -t ar -s 1 -status 0
32729 zhouds 20 0 1958m 41m 936 S 4.6 0.5 62:54.17 hsserver -f front_demo.xml -start mainsvr -t ar -s 0 -status 0
32740 zhouds 20 0 2818m 35m 736 S 4.6 0.4 71:29.01 /home/zhouds/linux.x64/bin/hsserver -f queue_demo.xml -t ar -s 0 -d /home/zhou
1307 shizj 20 0 144g 335m 800 S 4.0 4.2 60:50.38 hsserver -f shizj_uft.xml -start mainsvr -t ar -s 0 -uft_status 1 -system_type
498 zhouds 20 0 2722m 48m 5920 S 3.3 0.6 46:57.94 hsserver -f uft_demo.xml -start mainsvr -t ar -s 0 -status 0 -system_type 0 -l
1496 shizj 20 0 26.6g 11m 1188 S 3.3 0.1 43:37.45 hsserver -f shizj_init.xml -start mainsvr -t ar -s 0 -status 0
30829 huangc 20 0 1355m 19m 796 S 3.3 0.2 45:27.38 /home/huangc/linux.x64/bin/hsserver -f warmstandby_hc.xml -t ar -s 1 -d /home/
1303 shizj 20 0 1286m 6120 728 S 2.3 0.1 30:22.74 hsserver -f shizj_arb.xml -start arbsvr -t ar -s 0 -status 0
32723 zhouds 20 0 1234m 17m 668 S 2.3 0.2 33:27.00 hsserver -f arb_demo.xml -start arbsvr -t ar -s 0 -status 0
32725 zhouds 20 0 614m 632 392 S 1.6 0.0 17:38.62 hsserver -f queue_demo.xml -start proxysvr -t ar -s 0 -status 0
13284 huangc 20 0 15036 1336 948 R 1.0 0.0 0:00.10 top
1341 root 20 0 82292 1412 1104 S 0.3 0.0 154:38.71 /usr/sbin/vmtoolsd
1750 root 20 0 13584 288 220 S 0.3 0.0 15:07.26 lldpad -d
1 root 20 0 19364 312 136 S 0.0 0.0 0:15.99 /sbin/init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.68 [kthreadd]
3 root RT 0 0 0 0 S 0.0 0.0 0:10.29 [migration/0]
4 root 20 0 0 0 0 S 0.0 0.0 36:04.74 [ksoftirqd/0]
5 root RT 0 0 0 0 S 0.0 0.0 0:00.00 [migration/0]
[huangc@V-02-01-00860 ~]$
top
的输出结果中包括以下信息：
- 第 1行显示系统正常运行时间，包括当前时间、 系统自从上次重启后已运行的时间长度、 当前用户数量， 以及 3个用于表示在先前的 1min、 5min和 15min内准备运行的平均处理器数目的平均负荷值。
- 第 2行给出进程的统计信息，包括在 top输出结果的上次更新之际正在运行的进程总数。 这一行还显示睡眠中的进程、 运行中的进程、 僵尸进程以及已停止进程的数目。
- 第 3行和第 4行显示各个 CPU的统计信息，包括用户进程、 系统进程、 niced进程以及空闲进程所占用的CPU时间百分比。
- 第 5行提供了内存统计信息，包括内存总量、已用内存量、空闲内存量、不同进程共享的内存量，以及用作缓冲区的内存量。
- 第 6行显示了虚存或交换活动的统计信息，包括交换空间总量、已用的交换空间大小、空闲的交换空间大小以及缓存的交换空间大小。
其余各行显示了具体进程的统计信息。一些更有用的
top
参数如下所示：
- d 输出数据的更新延迟。
- p 只显示指定进程的信息。最多可指定 20个进程。
- S 显示进程及其子进程所占用时间的汇总信息，还给出进程的停工时间。
- I 不报告空闲进程的信息。
- H 显示进程的所有线程信息。
- N 生成报告的次数。
top
还提供了一种动态模式修改所报告的信息。按下
F
键可以激活动态模式。再按下
J
键， 就可以添加一个新列来显示某个当前执行的进程最近使用的
CPU
时间。
三、sar工具
sar
是
sysstat
工具包的组成部分。它收集并报告操作系统中广泛的系统活动，包括
CPU
利用率、 上下文切换和中断速率、 页换入和页换出速率、 共享内存使用情况、 缓冲区使用情况以及网络使用情况。
sar(1)
工具很有用， 它不断地收集系统活动信息并将其记
录到一组日志文件中，从而有可能在报告性能衰退事件之前以及在该事件之后评估性能问题。
sar
常常用于确定事件的时间，也可用于标识特定的系统行为变化。
sar
可以使用更短的时间间隔或固定数目的时间间隔来输出信息，这非常类似于
vmstat
。基于数量和时间间隔参数的取值，
sar
工具以指定的时间间隔
(
以秒为单位
)
执行指定次数的信息输出操作。另外，
sar
可以为所收集的许多数据点提供平均信息。
1、CPU利用率
[huangc@V-02-01-00860 ~]$ sar -u -P ALL -C 5
Linux 2.6.32-431.el6.x86_64 (V-02-01-00860) 10/12/16 _x86_64_ (2 CPU)
15:50:19 CPU %user %nice %system %iowait %steal %idle
15:50:24 all 3.38 0.00 5.28 0.00 0.00 91.34
15:50:24 0 3.39 0.00 5.30 0.00 0.00 91.31
15:50:24 1 3.36 0.00 5.25 0.00 0.00 91.39
15:50:24 CPU %user %nice %system %iowait %steal %idle
15:50:29 all 3.17 0.00 4.66 0.00 0.00 92.17
15:50:29 0 3.40 0.00 4.25 0.00 0.00 92.36
15:50:29 1 2.75 0.00 5.08 0.00 0.00 92.16
15:50:29 CPU %user %nice %system %iowait %steal %idle
15:50:34 all 2.95 0.00 5.16 0.00 0.00 91.89
15:50:34 0 3.36 0.00 5.25 0.00 0.00 91.39
15:50:34 1 2.75 0.00 4.86 0.00 0.00 92.39
网络和磁盘服务进程是耗用
CPU
的系统组件之一。当操作系统生成
I/O
活动时， 相应的设备子系统会作出响应，并使用硬件中断信号来指示
I/O
请求已完成。 操作系统对这些中断进行计数。 输出结果有助于可视化呈现网络和磁盘
I/O
活动的速率。
sar(1)
提供了这种输入。利用性能基线也许可以对系统中断速率进行跟踪，这将是操作系统开销的另一个来源或者系统性能潜在变化的指示器。“
-I SUM
” 选项可以生成如下信息，包括每秒的中断总次数。“
-I ALL
” 选项可以为每个中断源提供类似信息
(
未显示
)。
2、中断速率
10:53:53 INTR intr/s
10:53:58 sum 4477.60
10:54:03 sum 6422.80
10:54:08 sum 6407.20
10:54:13 sum 6111.4010:54:18 sum 6095.40
10:54:23 sum 6104.81
10:54:28 sum 6149.80
. . .
Average: sum 4416.5 在
可以通过
sar -A
命令获得基于
CPU
的中断分布视图
(
以下示例摘录自完整的输出结果
)
。注意系统的
IRQ
取值为
0
、
1
、
2
、
9
、
12
、
14
、
17
、
18
、
21
、
23
、
24
和
25
。
3、中断分布
中断分布的研究可能揭示出中断处理机制中的不平衡性。下一步需要对调度器进行分析。解决该问题的一种方法是通过为特定设备的中断(或 IRQ)设置与某个特定 CPU或一组 CPU相关的亲合度，将 IRQ处理绑定到特定的某个处理器或许多处理器上。 例
如，如果 0x0001被回显到/proc/irq/ID(其中 ID对应于一个设备)，则只有 CPU 0才处理该设备的 IRQ；如果 0x000f被回显到/proc/irq/ID，则 CPU 0～CPU 3将负责处理该设备的 IRQ。对于某些工作负荷而言，这种技术可以减少在繁重使用的特定处理器上发生的竞争现象。这项技术可以更高效地处理 I/O中断，从而相应地提高 I/O性能 。
