linux系统性能监控--CPU利用率

    在对系统的方法化分析中，首要且最基本的工具之一常常是对系统的 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: 0vendor_id: GenuineIntelcpu family: 6model: 62model name: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHzstepping: 4cpu MHz: 2500.000cache size: 25600 KBphysical id: 0siblings: 2core id: 0cpu cores: 2apicid: 0initial apicid: 0fpu: yesfpu_exception: yescpuid level: 13wp: yesflags: 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 smepbogomips: 5000.00clflush size: 64cache_alignment: 64address sizes: 40 bits physical, 48 bits virtualpower management:processor: 1vendor_id: GenuineIntelcpu family: 6model: 62model name: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHzstepping: 4cpu MHz: 2500.000cache size: 25600 KBphysical id: 0siblings: 2core id: 1cpu cores: 2apicid: 1initial apicid: 1fpu: yesfpu_exception: yescpuid level: 13wp: yesflags: 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 smepbogomips: 5000.00clflush size: 64cache_alignment: 64address sizes: 40 bits physical, 48 bits virtualpower 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的活动情况 。
• swap部分提供了从磁盘上换入的内存容量(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工具

    top和gtop工具非常有助于对导致生成vmstat或uptime所显示的高层信息的任务和进程加以理解。它们可以显示哪些进程是活跃的以及哪些进程消耗的处理时间或内存最多。

    top命令对于所有正在运行的进程和系统载荷提供不断更新的概览信息，包括 CPU负荷、 内存使用以及每个进程的内存使用情况，具体如下面的快照内容所述。注意top也提供了负荷平均值的快照，这非常类似于 uptime(1)的做法；然而， top也提供了关于被创建但当前正在休眠的进程数量以及正在运行的进程数量的分类汇总信息。“ 休眠”任务是那些处于被阻塞并等待某项活动的任务， 例如用户对键盘的一次按键、来自管道或 socket的数据、来自另一台主机(例如，等待别人发出内容请求的 Web服务器)的请求等。 top(1)还单独显示了每个处理器的负荷平均值， 这有助于识别在调度任务过程中的任何不均衡性。默认状态下， top的输出被经常地刷新，且把任务基于 CPU占用时间的百分比排序。当然也可能存在着其他排序选项，例如CPU累加消耗量或者内存消耗百分比 。

[huangc@V-02-01-00860 ~]$ toptop - 15:17:44 up 78 days,  5:17, 13 users,  load average: 0.00, 0.10, 0.12Tasks: 227 total,   1 running, 225 sleeping,   1 stopped,   0 zombieCpu(s):  7.8%us, 12.1%sy,  0.0%ni, 79.9%id,  0.0%wa,  0.0%hi,  0.2%si,  0.0%stMem:   8193720k total,  6315000k used,  1878720k free,    47436k buffersSwap:  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.p30824 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 5Linux 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     %idle15:50:24        all      3.38      0.00      5.28      0.00      0.00     91.3415:50:24          0      3.39      0.00      5.30      0.00      0.00     91.3115:50:24          1      3.36      0.00      5.25      0.00      0.00     91.3915:50:24        CPU     %user     %nice   %system   %iowait    %steal     %idle15:50:29        all      3.17      0.00      4.66      0.00      0.00     92.1715:50:29          0      3.40      0.00      4.25      0.00      0.00     92.3615:50:29          1      2.75      0.00      5.08      0.00      0.00     92.1615:50:29        CPU     %user     %nice   %system   %iowait    %steal     %idle15:50:34        all      2.95      0.00      5.16      0.00      0.00     91.8915:50:34          0      3.36      0.00      5.25      0.00      0.00     91.3915: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/s10:53:58 sum 4477.6010:54:03 sum 6422.8010:54:08 sum 6407.2010:54:13 sum 6111.4010:54:18 sum 6095.4010:54:23 sum 6104.8110: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性能 。