分类:
2010-12-29 16:11:10
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 使用情况被分解为四种类别:
最后一行是所有数据点的平均值。然而,因为大多数系统都会在忙时间段后经历空闲时间段,所以平均值并不能反映完整的情况。
同时,对磁盘活动也进行了监视。高磁盘使用率意味着,从磁盘请求数据的应用程序更有可能会被阻塞(暂停),直到磁盘为该进程做好准备。通常,解决方案涉及到将文件系统拆分到不同的磁盘或阵列。然而,第一步是要知道出现了问题。
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 |
和前面的示例一样,最左边的是时间。其他列如下:
其中的一些数值,如 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。假设您当时正在调查较差性能的要求,那么从这些数据中可以得到什么结论呢?
sar -b
为百分之 31,同时每秒 16,000 个盘块)。该磁盘是 home 目录分区,根据用户想要完成的任务不同,他/她可能会遇到较慢的响应。快速查看该时间段内的 CPU 使用情况,显示出系统大约占用了百分之 80 的 CPU,剩下的用于用户任务。作为系统管理员,可以通过下面三种方式使用这一信息:
cron
工作关联。在本例中,看来已经将问题隔离出来了,出于该原因,我有意地使用 Shell 脚本来运转磁盘以创建一些有趣的 sar
报告!然而发现了一个趋势,如在工作时间内 home 驱动器比较繁忙,关于该问题可能存在完成某项任务的调用。可能的解决方案包括,将 home
目录拆分到其他磁盘、安装高速磁盘或将其转移到其他地方,如 Network Attached Storage (NAS)。
以周期性的间隔获取关于系统的定性数据,这是查找性能瓶颈并确定是否需要进一步操作的有效方法。可以使用 SAR 及其相关实用程序来完成这项任务,每隔十分钟获取一次快照并使用前端工具来访问这些数据。尽管实际上需要一定的策略,但系统管理员可以使用所提供的大量信 息来发现系统中出现的问题,以及确定是否需要进行进一步的调查工作。
学习
sar
命令结果的更详细的解释。sar
,那么也有可能会喜欢 iostat
和 vmstat
,您可以使用它们对当前系统活动进行更深入地研究。 概述了这些工具的使用,以及关于 sar
更详细的信息。和 sar
一样,大多数的信息都适用于其他 UNIX 版本。获得产品和技术
讨论
从 1994 开始,Sean Walberg 就一直在学术、企业和 Internet 服务提供者环境中从事 Linux 和 UNIX 系统的研究。在过去几年里,他撰写了大量有关系统管理的文章。您可以通过 与 Sean 联系。