使用 SAR 进行简单的系统监视--SAR 将帮助您确定性能瓶颈

Sean Walberg (), 高级网络工程师, P.Eng

2006 年 5 月 25 日

---

了解如何将用户抱怨与系统活动报告程序 (SAR) 关联，并使用 SAR 日志针对趋势建立性能基准。SAR 是系统管理员的理想工具。它以周期性的间隔捕获系统性能度量。

用户总是在出现性能问题之后才想到它们。“为什么有些问题以前并不重要，而现在却变得重要了呢？”，如果忽略这样的问题，那么问题就变成了“系统在 出现所谓的问题时状态如何呢？”。通过周期性地获取性能快照和查看数据，您就离确定问题的原因并创建相应的解决方案更近了一步。

您的系统捆绑了 SAR 实用程序套件（事实上，大多数版本的 UNIX® 都安装了 SAR），但可能还没有启用。要启用 SAR，必须通过 cron 工具以周期性的间隔运行某些实用程序。在以 root 用户身份运行时，使用 crontab -e 命令，然后提供如清单 1 所示的配置。

# Collect measurements at 10-minute intervals
0,10,20,30,40,50   * * * *   /usr/lib/sa/sa1
# Create daily reports and purge old files
0                  0 * * *   /usr/lib/sa/sa2 -A

第一个命令 sa1，是调用 sadc 以将性能数据收集到二进制日志文件中的一个 Shell 脚本。sa1 命令还确保了每天都使用不同的文件，我将在时间是最重要的部分中对这一点进行解释。每隔十分钟运行一次该命令，这是粒度和系统性能影响之间的折衷办法。

第二个命令 sa2，是将当日二进制日志文件中所有的数据转储到文本文件的另一个 Shell 脚本，然后它将清除七天之前的所有日志文件。参数 -A 指定了从二进制文件中提取哪些数据转储到文本文件中。尽管可以阅读文本文件以查看系统该日的状态，但我将介绍如何更精确地查询二进制日志文件。

已经收集到了相应的数据，但是必须通过查询才能使其更有价值。不带选项运行 sar 命令，这将生成关于当日 CPU 使用情况的基本统计信息。清单 2 显示了不带任何选项的 sar 命令的输出结果。（在不同的平台中，可能会看到不同的列名。在一些 UNIX 版本中，sadc 命令将根据可用的信息来收集不同的数据。）这里的示例来自于 Sun Solaris 10，无论使用什么平台都是类似的，但列名可能会稍有不同。

-bash-3.00$ sar

SunOS unknown 5.10 Generic_118822-23 sun4u    01/20/2006

00:00:01    %usr    %sys    %wio   %idle
00:10:00       0       0       0     100
. cut ...
09:30:00       4      47       0      49

Average        0       1       0      98

sar 命令输出中的每一行都是一项单独的度量，并且在最左边的列中显示了时间戳。其他列中则存放了相应的数据。（根据命令行所使用参数的不同，这些列也会有所不同。）在清单 2 中，CPU 使用情况被分解为四种类别：

• %usr： CPU 花费在用户进程（如应用程序、Shell 脚本或与该用户进行的交互）上的时间的百分比。
• %sys： CPU 用来执行核心任务的时间的百分比。在本示例中该数字比较大，这是因为我正从核心随机数生成器获取数据。
• %wio： CPU 等待块设备（如磁盘）输入或输出的时间的百分比。
• %idle： CPU 未进行任何有用操作的时间的百分比。

最后一行是所有数据点的平均值。然而，因为大多数系统都会在忙时间段后经历空闲时间段，所以平均值并不能反映完整的情况。

同时，对磁盘活动也进行了监视。高磁盘使用率意味着，从磁盘请求数据的应用程序更有可能会被阻塞（暂停），直到磁盘为该进程做好准备。通常，解决方案涉及到将文件系统拆分到不同的磁盘或阵列。然而，第一步是要知道出现了问题。

sar -d 的输出显示了一个度量时间段内各种与磁盘相关的统计数据。为了更加简洁，清单 3 仅显示了硬盘驱动器的活动。

$ sar -d

SunOS unknown 5.10 Generic_118822-23 sun4u    01/22/2006

00:00:01   device       %busy   avque   r+w/s  blks/s  avwait  avserv
. cut ...
14:00:02   dad0             31     0.6      78   16102     1.9     5.3
           dad0,c            0     0.0       0       0     0.0     0.0
           dad0,h           31     0.6      78   16102     1.9     5.3
           dad1              0     0.0       0       1     1.6     1.3
           dad1,a            0     0.0       0       1     1.6     1.3
           dad1,b            0     0.0       0       0     0.0     0.0
           dad1,c            0     0.0       0       0     0.0     0.0

和前面的示例一样，最左边的是时间。其他列如下：

• device： 这是指正在进行测量的磁盘或磁盘分区。在 Sun Solaris 中，必须通过查找 /etc/path_to_inst 中所报告的名称将该磁盘转换为物理磁盘，然后将该信息交叉引用到 /dev/dsk 中的项目。在 Linux® 中，使用了磁盘设备的主从设备号。
• %busy： 这是读取或写入设备的时间的百分比。
• avque： 这是用来串行化磁盘活动的队列的平均深度。avque 的值越大，发生的阻塞就越多。
• r+w/s、blks/s：这分别是用每秒的读或写操作和磁盘盘块来表示的磁盘活动。
• avwait：这是磁盘读或写操作等待执行的平均时间（单位为毫秒）。
• avserv：这是磁盘读或写操作所执行的平均时间（单位为毫秒）。

其中的一些数值，如 avwait 和 avserv 值，直接关系到用户体验。磁盘的高等待时间可能表示多个人正在竞争使用该磁盘，这一点可以通过高 avque 数值来证实。高 avserv 值表示磁盘的速度较慢。

同时还收集了许多其他的项目，可使用相应的参数来查看它们：

• -b 参数显示了缓冲区信息和使用缓冲区与必须写磁盘的比率。
• -c 参数显示了系统调用分解为一些常用的调用，如 fork()、exec()、read() 和 write()。高进程创建会导致较差的性能，并且这是可能需要将一些应用程序转移到其他计算机的信号。
• -g、-p 和 -w 参数显示了分页（交换）活动。高分页操作是内存缺乏的信号。特别地，-w 选项显示了进程切换的次数：高的数值表示计算机上运行的内容过多，该计算机在切换任务上花费了比实际工作更多的时间。
• -q 参数显示了运行队列的大小，它与当时的平均负载相同。
• -r 参数显示了一段时间的可用内存和交换空间。

每种 UNIX 版本都对 sar 实现了自己的度量集合和命令行参数。我介绍的这些都是比较常见的，并且代表了更加有用的元素。

到此为止，示例显示了当日的数据，它虽然具有相应的作用，但也存在着两个问题：

• 感兴趣的是一个小时内的数据，但获得的是一整天的。
• 需要返回到不同的日期。

正如前面看到的，sa1 将每天的数据保存到不同的文件中。查看 sa1 脚本，会发现所使用的目录，如果是 Sun Solaris 10，该目录为 /var/adm/sa。该目录中有一些文件，它们以“sa”或“sar”开头，后跟一个数字。这个数字表示一个月中的第几天，以“sar”开头的文件是该日数据的文本转储（由夜间运行的 sa2 所创建），而以“sa”开头的文件保存着数据的二进制版本。实际上，包含当前日期的文件是启动 sar 时所读取的文件。

为 sar 命令指定 -f 以选择要读取的文件。如果今天是一个月中的第 23 日，可以使用命令 sar -f /var/adm/sa/sa22 来读取 sa22 以查看昨天的数据。还可以传递介绍过的其他参数以访问不同类型的数据。

可以做的第二件事情是，通过使用 -s 和 -e 参数（即开始 和结束）来指定具体时间以缩小查询的范围。请注意，-s 并不是包含性的，所以必须从所选择的开始时间中多减去十分钟。继续前面的示例，清单 4 显示了交换文件的使用情况和从第 22 天的 2:30 p.m. 到 3:00 p.m 的运行队列。

# sar -f /var/adm/sa/sa22 -s 14:20 -e 15:00 -w -q -i 4

SunOS unknown 5.10 Generic_118822-23 sun4u    01/22/2006

14:20:00 swpin/s bswin/s swpot/s bswot/s pswch/s
14:30:00    0.00     0.0    0.00     0.0     140
14:40:01    0.00     0.0    0.00     0.0     144
14:50:01    0.00     0.0    0.00     0.0     140
15:00:00    0.00     0.0    0.00     0.0     139

Average     0.00     0.0    0.00     0.0     140

14:20:00 runq-sz %runocc swpq-sz %swpocc
14:30:00    10.5     100     0.0       0
14:40:01    10.5     100     0.0       0
14:50:01    10.4     100     0.0       0
15:00:00    10.5     100     0.0       0

Average     10.5     100     0.0       0

简单查看一下清单 4，它显示出交换活动为零，每秒大约发生 140 次进程切换，并且平均负载略高于 10。假设您当时正在调查较差性能的要求，那么从这些数据中可以得到什么结论呢？

• 因为没有发现交换过程，无论在运行什么进程，它们并没有消耗大量的内存。
• 该问题可能是由一组长时间运行的进程所导致，因为运行队列和进程切换相对稳定。如果以前并不是这样，那么可以怀疑是应用程序级的问题，如繁忙的 Web 服务器。
• 由于了解到清单 3 的输出显示了同一时间段的其他数据，您可以查看某块使用频繁的磁盘（根据 sar -b 为百分之 31，同时每秒 16,000 个盘块）。该磁盘是 home 目录分区，根据用户想要完成的任务不同，他/她可能会遇到较慢的响应。

快速查看该时间段内的 CPU 使用情况，显示出系统大约占用了百分之 80 的 CPU，剩下的用于用户任务。作为系统管理员，可以通过下面三种方式使用这一信息：

• 回到前几天的日志中。在本例中，我发现问题开始于 1:00 p.m.，并于第二天早上结束。
• 尝试将该活动与任何可能在该日开始的 cron 工作关联。
• 尝试找到其趋势。查看另外几天的数据，我发现性能是正常的，这并不表示系统已经达到其上限。

在本例中，看来已经将问题隔离出来了，出于该原因，我有意地使用 Shell 脚本来运转磁盘以创建一些有趣的 sar 报告！然而发现了一个趋势，如在工作时间内 home 驱动器比较繁忙，关于该问题可能存在完成某项任务的调用。可能的解决方案包括，将 home 目录拆分到其他磁盘、安装高速磁盘或将其转移到其他地方，如 Network Attached Storage (NAS)。

以周期性的间隔获取关于系统的定性数据，这是查找性能瓶颈并确定是否需要进一步操作的有效方法。可以使用 SAR 及其相关实用程序来完成这项任务，每隔十分钟获取一次快照并使用前端工具来访问这些数据。尽管实际上需要一定的策略，但系统管理员可以使用所提供的大量信 息来发现系统中出现的问题，以及确定是否需要进行进一步的调查工作。

 

学习

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文
  
  
• SAR 运行于大多数 UNIX 版本中，包括 、 和 。
  
  
• 跟踪最新的 developerWorks 技术事件与网络广播。
  
  
• 栏目为 Solaris 性能优化提供了一些有价值的建议，包括对 sar 命令结果的更详细的解释。
  
  
• 如果您喜欢上了 sar，那么也有可能会喜欢 iostat 和 vmstat，您可以使用它们对当前系统活动进行更深入地研究。 概述了这些工具的使用，以及关于 sar 更详细的信息。和 sar 一样，大多数的信息都适用于其他 UNIX 版本。
  
  
• 我曾撰写了关于 命令来监视 Linux 当前活动的文章，它们也适用于 AIX、Solaris 和 HP-UX 等系统。

获得产品和技术

• 使用 IBM 试用软件开发您的下一个项目，可直接从 developerWorks 下载这些试用软件。
  
  
• 具有以 SAR 为基础提供数据图形视图的商业产品。可以获得其。
  
  

讨论

• 是讨论 Solaris 性能优化和其他 Solaris 问题的好地方。
  
  
• 参与 developerWorks 博客，从而参加到 developerWorks 社区中来。
  
  

 

		从 1994 开始，Sean Walberg 就一直在学术、企业和 Internet 服务提供者环境中从事 Linux 和 UNIX 系统的研究。在过去几年里，他撰写了大量有关系统管理的文章。您可以通过 与 Sean 联系。