用户似乎会在发生性能问题后的某个时间记住它们。 忽略“如果不那么重要，为什么现在那么重要？” 您很想问的一个问题，问题就变成了：“所称问题发生时系统的状况是什么？” 通过定期获取性能快照并查看数据，您可以更精确地查明问题的根源并创建解决方案。
SAR实用程序套件与系统捆绑在一起（实际上，它已安装在大多数UNIX®上），但可能未启用。 要启用SAR，您必须通过cron设施定期运行一些实用程序。 以root用户身份运行时使用crontab -e命令，然后提供清单1所示的配置。
第一个命令sa1是一个外壳脚本，该脚本调用sadc来将性能数据收集在二进制日志文件中。 sa1命令还确保每天都有自己的文件，我在“ 时间就是一切”部分中解释了该文件。 每十分钟运行一次此命令，这是粒度与系统影响之间的良好折衷。
第二个命令sa2是另一个shell脚本，它将当前日期的二进制日志文件中的所有数据转储到文本文件中，然后清除所有早于7天的日志文件。 -A参数指定从二进制文件提取到文本文件的内容。 尽管您可以阅读文本文件以查看当天的系统状态，但我将向您展示如何查询二进制日志文件，以更加精确。
正在收集数据，但是必须查询它才有用。 运行不带选项的sar命令将生成有关当天CPU使用率的基本统计信息。 清单2显示了不带任何参数的sar的输出。 （根据平台的不同，您可能会看到不同的列名称。在某些UNIX风格中， sadc根据可用的内容收集或多或少的数据。） 您使用的平台都将相似，但列名可能略有不同。
sar输出中的每一行都是单个度量，时间戳记在最左侧的列中。 其他列保存数据。 （这些列根据您使用的命令行参数而有所不同。）在清单2中 ，CPU使用情况分为四类：
％usr： CPU在用户进程（例如应用程序，shell脚本或与用户进行交互）上花费的时间百分比。 ％sys： CPU花在执行内核任务上的时间百分比。 在此示例中，该数字很高，因为我是从内核的随机数生成器提取数据的。 ％wio： CPU等待块设备（例如磁盘）的输入或输出的时间百分比。 ％idle： CPU未执行任何有用操作的时间百分比。最后一行是所有数据点的平均值。 但是，由于大多数系统都会经历繁忙的时段，然后是空闲的时段，因此平均值无法说明全部情况。
磁盘活动也受到监视。 高磁盘使用率意味着从磁盘请求数据的应用程序更有可能阻塞（暂停），直到磁盘为该过程做好准备为止。 该解决方案通常涉及跨磁盘或阵列拆分文件系统。 但是，第一步是要知道您有问题。
sar -d的输出显示一个测量周期内与磁盘相关的各种统计信息。 为简洁起见， 清单3仅显示了硬盘驱动器活动。
与前面的示例一样，时间在左侧。 其他列如下：
设备：这是正在测量的磁盘或磁盘分区。 在Sun Solaris中，必须通过在/ etc / path_to_inst中查找报告的名称，然后将该信息交叉引用到/ dev / dsk中的条目，来将该磁盘转换为物理磁盘。 在Linux®中，使用磁盘设备的主设备号和次设备号。 ％busy：这是读取或写入设备的时间百分比。 平均：这是用于序列化磁盘活动的队列的平均深度。 平均值越高，发生的阻塞越多。 r + w / s，blks / s：这是分别根据读取或写入操作和磁盘块而言的每秒磁盘活动。 avwait：这是磁盘读取或写入操作在执行之前等待的平均时间（以毫秒为单位）。 avserv：这是磁盘读取或写入操作执行的平均时间（以毫秒为单位）。其中一些数字（例如avwait和avserv值）直接与用户体验相关。 磁盘上的高等待时间可能表明有好几个人在争夺该磁盘，应使用较高的平均数字来确认。 较高的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参数（请考虑start和end ）来指定时间。 请注意， -s不包括在内，因此您必须从所选的开始时间中减去额外的十分钟。 继续前面的示例， 清单4显示了交换文件的使用情况以及22号从2:30 pm到3:00 pm的运行队列。
清单4的简要显示表明，交换活动为NIL，每秒发生约140个过程切换，平均负载略大于10。 假设您当时正在调查性能不佳的声明，那么这将告诉您什么？
无论运行什么进程，都不会占用大量内存，因为您看不到交换。 可能是由于运行队列和进程开关相对一致，这是由一组长时间运行的进程引起的。 如果没有，您可能会怀疑应用程序级别的问题，例如繁忙的Web服务器。 知道清单3的输出显示的是同一时间段的一部分，您可以看到其中一个磁盘的使用率很高（根据sar -b使用率为31％，但每秒还有16,000个块）。 该磁盘是主目录分区； 根据用户尝试执行的操作，他或她的响应速度可能很慢。快速查看该时间段内的CPU使用率，可以发现系统占用了大约80％的CPU。 其余的则由用户任务消耗。 作为系统管理员，您可以通过三种方式使用此信息：
返回前几天的日志。 在这种情况下，我发现问题始于1:00 pm，并于第二天早晨结束。 尝试将活动与当天可能已开始的任何cron作业相关联。 尝试找到趋势。 查看几天后的数据，我发现性能是正常的，并不表示系统已达到极限。在这种情况下，问题似乎是孤立的，并且有充分的理由-我故意用shell脚本运行磁盘以创建一些有趣的sar报告！ 但是，如果出现了一种趋势，例如在工作时间内忙碌的家庭驱动器，那将是一个呼吁对此问题进行某些处理的电话。 可能的解决方案包括将主目录拆分到其他磁盘，安装更快的磁盘或移动到诸如网络连接存储（NAS）之类的方法。
定期获取有关系统的定性数据是查找性能瓶颈并确定是否需要采取进一步措施的有效方法。 SAR和相关实用程序就是这样做的-快照每十分钟拍摄一次，前端允许您访问此数据。 尽管本质上是战术性的，但仍提供了大量信息，使系统管理员可以发现系统的哪些方面正在遭受苦难以及是否需要进一步调查。
翻译自: https://www.ibm.com/developerworks/aix/library/au-unix-perfmonsar.html
相关资源：SAR图像的提取与显示