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