AIX 7监视内存的使用情况（ps、sar、svmon 和 vmstat）并分析其结果

转自https://www.ibm.com/developerworks/cn/aix/library/au-aix7memoryoptimize2/index.html

简介

内存子系统调优中最重要的部分并不涉及实际的调优工作。在对系统进行调优之前，必须弄清楚主机系统的实际运行情况。要做到这一点，AIX® 7 管理员必须知道应该使用何种工具以及如何对将要捕捉的数据进行分析。

再次重申前面的调优文章（见 参考资料）中所介绍的原则：必须先监视主机，才能对系统进行正确地调优，无论它是作为逻辑分区 (LPAR) 运行还是在自己的物理服务器上运行。可以使用许多命令来捕捉和分析数据，所以需要了解这些命令，以及其中的哪些命令最适合想要进行的工作。在捕捉了数据之后，需要对结果进行分析。有些问题初看起来像是 CPU 的问题，但是经过分析之后，可以诊断出是内存或 I/O 问题，前提是使用合适的工具捕捉数据并知道如何进行分析工作。只有在正确地完成了这些工作之后，才可以考虑对系统进行实际的更改。如果医生不了解病史和目前的症状，就无法诊治疾病；同样，也需要在优化子系统之前对其进行诊断。如果在出现 CPU 或者 I/O 瓶颈的情况下对内存子系统进行优化，这将是毫无帮助的，甚至可能会影响主机的正常运行。

本文将帮助您理解正确地进行诊断的重要性。您将看到，性能调优远不只是实际的调优工作本身。在您将要学习的工具中，有一些是通用的监视工具，所有版本的 UNIX® 都提供这些工具，另外一些工具是专门为 AIX 7 编写的。必须获得基准数据；这是已知环境的关键数据，调优决策都以此作为基础。

不要等到用户开始向服务台抱怨糟糕的性能时，才开始监视系统。应该在将服务器投入生产环境中后尽快捕捉数据。如果做到了这一点，那么就可以积极主动地进行调优，其目标是在用户指出问题之前找到它。如果不了解系统正常运行时的数据，那么就无法确定所查看的数据是否表示存在性能问题。这是所有适当的性能调优方法的一部分；必须有效地捕捉数据，并正确地分析结果和趋势。我们来仔细地讨论内存监视。

UNIX 通用的内存监视

在本节中，我们概述在所有 UNIX 发行版中都可以使用的一些通用 UNIX 工具，包括 ps、sar 和 vmstat。其中的大多数工具都允许快速地对性能问题进行故障排除，但是它们并不适用于进行历史趋势研究和分析。

大多数管理员不经常使用 ps 命令对可能存在的内存瓶颈进行故障排除。但是，ps 可以提供关于系统运行情况的大量信息，因此有助于了解使用内存的情况。ps 最常用的功能是查看系统中正在运行的进程（见 清单 1）。

清单 1. 使用 ps 查看系统中正在运行的进程

最常见的 ps 输出格式对于研究内存问题不太有用，但是有时候能让您回忆起在使用大量内存的系统上运行的一个进程。

但是，还有其他输出格式，其中最有用的是使用 BSD 风格的格式 u 或 v，它们显示每个进程的内存使用情况报告。下面的示例显示系统中每个活动进程的内存使用情况，并以恰当的方式排序。

清单 2. 每个活动进程的内存使用情况

各个列提供关于内存使用情况的详细信息：

• RSS — 每个进程用于文本和数据段的 RAM 量。PID 15256 使用 7232k 内存。这是此进程正在使用的真实内存。
• %MEM — RSS 的实际量 / RAM 总量。应该进一步检查使用的内存百分比高的进程，但是应该记住数据库和 HPC 应用程序在正常情况下可以使用大量内存，可以不理会它们。在通用的系统上，任何进程都可能使用大量内存。
• TRS — 用于进程文本段的 RAM 量（单位为 KB）。
• SIZE — 为此进程（文本和数据）分配的分页空间的实际大小。

尽管这个命令提供一些有价值的信息，但是除非有可信的管理员已经诊断出系统中存在某种内存问题，否则我们通常不会首先使用这个命令。应该使用 vmstat 来确定瓶颈的原因，即使在尚未确定它是否与内存有关的时候。vmstat 报告内核线程、CPU 活动、虚拟内存、分页、阻塞的磁盘 I/O 以及相关信息（见 清单 3）。要了解系统的运行情况，这是最快捷且最直接的方法。

清单 3. 使用 vmstat 确定瓶颈的原因

我们先来说明这些列所表示的含义：

• 内存数据
  • avm — 正在使用的活动虚拟内存量（4k 页面的数量），不包括文件页面。
  • fre — 内存空闲列表的大小。在大多数情况下，当这个值变得很小时我们并不担心，因为 AIX 7 总是会充分地使用内存，不会像希望的那样尽早地释放内存。这个设置由 vmo 命令的 minfree 参数确定。归根结底，分页信息更加重要。
  • pi — 从分页空间换入的页面数。
  • po — 换出到分页空间的页面数。
  • fr — 空闲的（被替换的）页面数。
  • sr — 为了判断是否需要替换而扫描的页面数。
  • cy — 为了替换而扫描页面所用的时钟周期数。
• CPU 和 I/O
  • r — 在指定的时间间隔内，可运行内核线程的平均数量。
  • b — 在指定的时间间隔内，位于虚拟内存等待队列中的内核线程的平均数量。如果 r 不大于 b，通常是 CPU 问题的现象，这可能是由于 I/O 或者内存瓶颈造成的。
  • us — 用户时间。
  • sy — 系统时间。
  • id — 空闲时间。
  • wa — 等待 I/O。
  • ec — 消耗容量的百分比，即，在运行共享处理器的系统上，您正使用的分配 CPU 时间多少的一个指标。
  • rc — 消耗的共享处理器资源的百分比。

对于工作负载分区 (WPAR)，还应该监视特定 WPAR 的内存使用情况，从而了解是否需要重新配置 WPAR。可以使用 -@ 命令行参数并指定 WPAR 名称来查明这一信息。

让我们回到 vmstat 的输出，系统究竟出现了什么问题呢？首先是一条警告：请不要只根据 vmstat 的简单输出，向高级管理人员提交详细的分析和调优战略建议。必须做更多的工作，才能正确地诊断出系统的问题。当碰到生产性能问题并需要立即了解系统的运行状况时，应该使用 vmstat，以便可以警告其他人出现了什么问题，或者马上采取合适的措施（如果可行的话）。

在 vmstat 的输出中，要查看的主要内容是分页信息。如果有大量页面换出活动 (po)，这常常说明真实内存不足，VMM 正在把分配的内存页面发送到磁盘上，以便为要换入的其他进程的页面让出空间。另外，要注意 I/O 统计数据，当发现阻塞的进程或者等待 I/O 的值 (wa) 很高时，这通常表示出现了实际的 I/O 问题，可能是正在等待文件访问，或者是与由于系统缺少内存而引起的分页相关的 I/O 问题。在这个示例中，看起来是后一种情况。我们碰到了 VMM 问题，这些问题可能导致了阻塞的进程和等待 I/O 的状况。通过优化内存参数，或者执行动态的 LPAR (DLPAR) 操作并在 LPAR 中添加更多 RAM，可以解决这个问题。

最后，如果使用动态的页面大小，还应该监视页面大小分配，以便更好地了解使用不同页面大小的情况。这有助于判断页面大小和配置是否正确。可以使用 vmstat -P ALL 获得此信息，见 清单 4。

清单 4. 获得页面大小统计信息

这里应用的规则与一般性统计数据一样，空闲页面少或页面换入/换出数量高都可能表明系统内存不足。

让我们进行更深入的研究。可以使用前面介绍过的 ps 命令尝试确定影响系统的进程。通常在这种情况下，我们会运行 sar 以检查该问题是否在使用另一种工具进行分析时依然存在。最好是使用多种工具以便提供进一步的帮助，从而确保诊断结果是正确的。

尽管与其他工具相比我们并不是很喜欢 sar（因为需要使用过多的标志，而且在诊断问题之前必须输入过多的命令），但是它允许实时地收集数据并查看以前捕捉的数据（使用 sadc）。大多数较早的工具只允许其中一种操作。差不多自从有了 UNIX，就有了 sar 命令，每个人都曾经使用过这个命令。使用 -r 标志可以提供一些 VMM 信息（见 清单 5）。

清单 5. 使用带 -r 标志的 sar 以获得 VMM 的信息

那么，这个结果究竟意味着什么呢？

• slots — 提供分页空间中空闲页面的数量。