AIX 5L 性能优化 监视 CPU

确定哪些 AIX® 工具可用于监视给定解决方案的中央处理器（Central Processing Unit，CPU），并了解为何某些工具优于其他工具。本系列的第 1 部分讨论了优化方法和使用 CPU 性能优化过程的重要性。另外还简单介绍了一些在优化存储库时可以使用的性能工具，对 POWER CPU 进行了简要介绍，并讨论了 POWER 芯片发展中的体系结构提升如何为 System p™ 产品系列的硬件提升做出贡献。

<!--start RESERVED FOR FUTURE USE INCLUDE FILES--><!-- include java script once we verify teams wants to use this and it will work on dbcs and cyrillic characters --><!--end RESERVED FOR FUTURE USE INCLUDE FILES-->

关于本系列

本系列包含三个部分，讨论中央处理器 (CPU) 性能和监视的各个方面。本系列的第 1 部分简单介绍了如何有效地监视 CPU，讨论了性能优化的方法，并给出了会对性能造成影响（正面影响或负面影响）的注意事项。尽管本系列的第 1 部分已经详细说明了一些命令，但第 2 部分将更集中于实际 CPU 系统监视的细节，以及趋势分析和结果。第 3 部分重点讨论通过主动控制线程使用和其他方法来最大限度地优化您的 CPU 性能。在整个系列文章中，我还将详细说明 AIX® CPU 性能优化和监视方面的各种最佳实践。

引言

性能优化显然不只是运行一些命令然后观察结果。UNIX® 管理员需要知道将哪些工具用于何种目的，以及捕获数据的最佳方法是什么。有时候您可能没有 30 天时间来通过系统地分析数据确定趋势，而有时候甚至都用不了 30 分钟就能够准确地判断出您的瓶颈所在。不管怎么说，这就是 CPU 监视的主要目的——准确地确定瓶颈。除非所搜集的数据清楚地表明 CPU 是瓶颈，否则并不希望进行 CPU 优化。事实上，我们经常会发现瓶颈与内存或 I/O 相关，而不是与 CPU 相关的问题。

作为 AIX 管理员，最重要的职责之一就是优化您的系统。如果不首先监视系统并分析结果，就不能进行优化。对于长期趋势和短期（接下来数小时内必须完成的工作）问题均是如此。虽然可以使用特定工具仅对 CPU 进行分析，但对于给定环境，可能要使用在系统上寻找所有可能瓶颈的工具。正如您可能已经知道的，CPU 是系统中最快的组件。如果您的 CPU 是瓶颈，将会对整个系统的性能造成影响。在我介绍这些工具时，请您注意以下命令已在 AIX 5.3 中进行了增强，允许工具使用 Advanced Power Virtualization 报告有关共享分区的准确统计数据：mpstat、sar、topas 和 vmstat。此外，还对以下基于跟踪的工具进行了更新：Curt、filemon、netpmon、pprof 和 splat。

闲话少说，接下来让我们开始着手监视系统。

UNIX 通用 CPU 监视工具

接下来我们将讨论在所有 UNIX 分发版本（Solaris 到 AIX）上可用的 UNIX 通用工具。虽然有些输出内容根据分发版本不同而有所变化，但大多数标志适用于所有 UNIX 系统。这些标志可帮助您动态地收集信息，但我不会依赖其确定历史趋势和进行分析。

我们首先讨论 vmstat。vmstat 报告关于进程、内存、分页、被阻塞的 I/O 及总体 CPU 活动的信息。虽然这个工具与虚拟内存相关（vmstat 中的 vm），但我发现在主机上运行 vmstat 可以让我快速而准确地确定 AIX 服务器上发生的情况。

使用 vmstat

您刚刚听到了我们非常不愿意听到的抱怨“为什么系统这么慢？”，需要快速进行分析，以确定可能的瓶颈位置。vmstat 是开始进行此工作的最好工具。有关运行 vmstat 的示例，请参见清单 1。

清单 1. 运行 vmstat

                        # vmstat 1
                        System configuration: lcpu=2 mem=3920MB
                        kthr    memory                page              faults          cpu
                        -----  -----------    ------------------------ ------------  -----------
                        r  b    avm   fre    re  pi  po  fr   sr  cy  in   sy  cs   us sy id wa
                        0  0  229367 332745   0   0   0   0    0   0   3  198  69    0  0 99  0
                        0  0  229367 332745   0   0   0   0    0   0   3   33  66    0  0 99  0
                        0  0  229367 332745   0   0   0   0    0   0   2   33  68    0  0 99  0
                        0  0  229367 332745   0   0   0   0    0   0  80  306 100    0  1 97  1
                        0  0  229367 332745   0   0   0   0    0   0   1   20  68    0  0 99  0
                        0  0  229367 332745   0   0   0   0    0   0   2   36  64    0  0 99  0
                        0  0  229367 332745   0   0   0   0    0   0   2   33  66    0  0 99  0
                        0  0  229367 332745   0   0   0   0    0   0   2   21  66    0  0 99  0
                        0  0  229367 332745   0   0   0   0    0   0   1  237  64    0  0 99  0
                        0  0  229367 332745   0   0   0   0    0   0   2   19  66    0  0 99  0
                        0  0  229367 332745   0   0   0   0    0   0   6   37  76    0  0 99  0
                        

 

此处要注意的最重要字段有：

• r——在所选择的任意采样间隔期间的平均可运行内核线程数。
• b——采样期间在虚拟内存中等待队列的平均内核线程数。r 应该始终高于 b；如果不是，通常意味着遇到了 CPU 瓶颈。
• fre——可用内存列表的大小。如果此数量并不小，不要太过担心。更为重要的是，在此数量小的情况下确定是否进行了任何分页操作。
• pi—— 从页面空间读取的页面。
• po——写入页面空间的页面。
• CPU 部分：
  • us
  • sy
  • id
  • wa

 

让我们看看最后一个部分（在大部分其他 CUP 监视工具中也提供此信息，不过使用的标题不同）：

• us——用户时间
• sy——系统时间
• id——空闲时间
• wa——等待 I/O

显然，此系统没有瓶颈。如何确定的呢？让我们看一看 vmstat 输出中要分析的更为重要的字段。尽管此系统运行的是 AIX 5.3，将不会看到物理处理器的数量或使用的可用容量的百分比，因为它不在微分区环境中运行。如果在微分区环境中运行，将看到这些额外的字段，因为对 vmstat 进行了增强，可以在虚拟环境和微分区环境工作。

如果您的 us 和 sys 条目都平均高于 80%，很可能遇到了 CPU 瓶颈。如果上升到了 100%，您的系统就真的太繁忙。如果这些数字很小，但 wa（等待 I/O）很高（通常大于 30），这意味着系统上存在 I/O 问题，从而导致 CPU 不能到达其最佳工作状态。如果 sy 时间 比 us 时间 长，这意味着您的系统处理数字的时间比实际处理内核数据的时间短。这也不好。

虽然 vmstat 命令更多地与内存相关，但我发现可通过该命令最快而且最准确地确定瓶颈所在。

那用户为什么会对系统抱怨呢？因为系统真的让用户感觉到运行得很慢。直到我确定了没有系统问题，而且相邻的同事没有出现问题，我才确定了问题的根源。因此，我让他重新启动 PC，从而获得干净的客户机系统。显然，某个正在运行的东西造成了 PC 客户机故障。

第二天我又接到另一个电话，于是再次启动 vmstat（请参见清单 2）。

清单 2. 再次运行 vmstat

                        # vmstat 1
                        System configuration: lcpu=2 mem=3920MB
                        kthr    memory              page              faults        cpu
                        ----- ----------- ------------------------ ------------  -----------
                        r  b   avm   fre   re  pi  po  fr   sr  cy  in  sy  cs   us sy id wa
                        9  0  4200  2746   0   0   0   0    0   0   3  198  69   70 30  0  0     0
                        4  7  4200  2746   0   0   0   0    0   0   3   33  66   67 31  2  0     0
                        2  6  4200  2746   0   0   0   0    0   0   2   33  68   65 34  1  0     0
                        3  9  4200  2746   0   0   0   0    0   0  80  306 100   80 20  0  1     0
                        2  7  4200  2746   0   0   0   0    0   0   1   20  68   80 20  0  0     0
                        

 

这又说明什么呢？

显然，此系统处于 CPU Bound 状态。没有进行分页，也没有任何 I/O 问题。有大量可运行线程，但没有足够的 CPU 周期来处理需要完成的工作。我得出这个结论花了多长时间？仅仅五秒钟。也可以尝试使用其他实用工具来进行此工作。

使用 sar

下一个命令 sar 是 UNIX System Activity Reporting 工具（属于 bos.acct 文件集）。此命令似乎已经成为了 UNIX 世界中永远存在的一员。此命令实际上就是将选择作为其标志的积累活动的内容写入到标准输出。例如，以下命令使用 -u 标志报告 CPU 统计数据。对于 vmstat，如果在虚拟环境中使用共享分区，将会报告两个其他信息列：physc 和 entc，这两个列分别定义分区所使用的物理处理器的数量以及所使用的可用容量。

我在没有用户的情况下在系统上运行此命令（请参见清单 3）。除非有批处理作业在运行，否则就不会看到大量的活动。

清单 3. 在没有用户的情况下运行 sar

                        # sar -u 1 5 (or sar 1 5)
                        AIX test01 3 5     03/18/07
                        System configuration: lcpu=2
                        17:36:53    %usr    %sys    %wio   %idle   physc
                        17:36:54       0       0       0     100    2.00
                        17:36:55       1       0       0     99     2.00
                        17:36:56       0       0       0     100    2.00
                        17:36:57       0       0       0     100    2.00
                        17:36:58       0       0       0     100    2.00
                        Average        0       0       0     100    2.00
                        

 

显然，此系统也没有 CPU 瓶颈。

上面所使用的列与 vmstat 条目输出类似。下表将 sar 与 vmstat 描述内容进行关联（请参见表 1）。

表 1. sar 输出字段和对应的 vmstat 字段

sar vmstat

%usr	us
%sys	sy
%wio	wa
%idle	id

我更喜欢使用 vmstat 而不是 sar 的一个原因是，它可提供 CPU 使用率信息，并能提供有关内存和 I/O 的总体监视信息。对于 sar，您需要运行独立的命令才能提取信息。sar 的一个优势是，它允许捕获日常信息和运行关于此信息的报告（不用自己撰写脚本来进行此工作）。它通过使用名为 System Activity Data Collector 的进程实现此工作，此进程实际是 sar 命令的一个后端进程。在已启用的情况下，它通常通过 cron（在缺省 AIX 分区上，通常会发现将其注释掉了）以二进制格式定期收集数据。

AIX 特定的 CPU 监视工具

接下来我们讨论特定于 AIX 的命令。编写这些命令的目的是为了让管理员在分区环境中监视系统。这些命令在使用 Advanced POWER Virtualization 功能（如共享处理器和微分区）时尤为有用。

使用 lparstat

当用户首次报告系统运行缓慢时，我决定启动 lparstat。lparstat 命令用于报告逻辑分区（Logical Partition，LPAR）信息和相关统计数据。在 AIX 5L V5.3 中，lparstat 命令将显示关于很多 POWER Hypervisor 调用的 Hypervisor 统计数据。lparstat 命令是一个相对较新的命令，通常用于在共享处理器分区环境中提供帮助。

因为我还希望看到 POWER Hypervisor 统计数据，因此使用了 -h 标志（如清单 4 中所示）。

清单 4. lparstat 命令的 -h 标志

                        # lparstat -h 1 5
                        System configuration: type=Dedicated mode=Capped smt=On lcpu=4 mem=3920
                        %user  %sys  %wait  %idle  %hypv hcalls
                        -----  ----  -----  -----  ----- ------
                        0.0   0.7    0.0   99.3   44.4 5933918
                        0.4   0.3    0.0   99.3   44.9 5898086
                        0.0   0.1    0.0   99.9   45.1 5930473
                        0.0   0.1    0.0   99.9   44.6 5931287
                        0.0   0.1    0.0   99.9   44.6 5931274
                        

 

正如您看到的，从某种程度而言，上面所生成的输出与 sar 命令相似。请注意，对于在专用环境或共享 Capped 环境中运行 AIX 5.2 或 AIX 5.3 的分区，总体 CPU 使用率基于 user、sys、wait 和 idle 值。在采用 Uncapped 模式运行的 AIX 5.3 分区中，使用率应该基于可用容量百分比。

mpstat

我经常使用的另一个命令是 mpstat 命令（请参见清单 5），该命令属于 bos.acct 文件集。这是专门为 AIX 5.3 创建的工具（与 lparstat 不同），用于显示分区系统上所有逻辑 CUP 的总体性能值。运行 mpstat 命令时，将显示两个部分的统计数据。第一部分显示系统配置，在该命令开始执行以及对系统配置进行了修改时，将显示这部分信息。第二部分显示使用率统计数据，此数据将以用户指定的时间为间隔显示。

清单 5. 运行 mpstat

                        # mpstat 1 1
                        System configuration: lcpu=2 ent=2.0
                        cpu min maj mpc int cs ics rq mig lpa sysc           us sy wa id  pc  %ec   lcs
                        0    0   0   0  164 83 40   0 1   100  17             0  0 0 100 0.17 8.3   113
                        1    0   0   0  102  1  1   1 0   100 3830453 66 34   0  0 0 100  .83 41.6
                        

 

我喜欢使用 mpstat 命令，因为它会采用非常清晰的格式报告所收集的分区上的每个逻辑 CPU 的信息。通过使用 -s 选项，甚至还能够看到同步多线程（Simultaneous MultiThreading，SMT）线程使用率。lparstat 和 mpstat 命令的缺点在于，二者都需要编写脚本和其他工具来处理数据格式和图形输出。实际上，您需要编写自己的 shell 脚本。尽管大部分管理员喜欢使用脚本，但他们却不愿意做重复工作。如果已经有了相应的工具来帮助您分析历史数据，编写自己的实用工具就不太明智了。

GUI 工具

接下来我们将了解一些实用工具，通过这些工具能以图形查看分析，还能对历史数据进行分析。尽管完全了解这些工具需要一定的时间，但这些工具比我们已经了解的命令行工具要更为灵活。

procmon

接下来我们讨论 procmon（请参见图 1）。此实用工具（在 AIX 5.3 中发布）不仅提供总体性能统计数据，还允许对实际运行的处理器进行操作。它允许管理员动态地结束进程或恢复进程。还可以将 procmon 数据导出到文件中，这就使其成为了一个不错的数据收集工具。procmon 实际上作为性能 Workbench 的插件运行，此 Workbench 可通过使用 perfwb（位于 /usr/bin 中）命令（属于 bos.perf.gtools.perfwb 文件集）启动。

图 1. procmon 输出

我之所以喜欢 procmon，是因为它允许对进程进行操作，而这可以提高系统的性能。虽然这个工具也有局限性，但我强烈建议您下载并使用此工具（我发现大多数管理员都不习惯使用此工具）。

topas

应该注意的另一个工具是 topas。老实说，尽管在 AIX 5.3 中有了大幅度提升，但我从来没有遇到过太多的 topas（属于 bos.perf.tools 文件集）迷。在进行这些更改前，它并不能捕获历史数据，也未针对在共享分区环境中使用而进行增强。通过这些更改，您可以从多个分区收集性能数据，切实地简化了 topas 作为性能管理和容量规划工具的功能。topas 的外观（请参见图 2）与 top 和 monitor（在其他 UNIX 变体中使用）非常相似。topas 是在屏幕上以基于文本的 GUI 格式显示所有信息的一款实用工具。采用其缺省模式时，会显示主机名、刷新间隔和 CPU、内存及 I/O 信息的综合情况。

图 2. topas 显示

有些新功能还包括允许在虚拟 I/O 服务器（Virtual I/O Server，VIO Server）上运行 topas。为此，请使用以下命令：

# topas -cecdisp
                        

 

 

在 LPAR 上，要运行：

topas -C
                        

 

 

考虑到在 5.3 TL 4 中引入了性能监视功能，topas 使用了从 inittab 自动启动的守护进程 xmwlm。在 AIX 5.3 的 TL_5 中，缺省会保留七天的数据，并会记录几乎所有的 topas 数据，除进程和工作负载管理器（Workload Manager，WLM）信息外，其中的其他数据会以交互方式显示。它使用 topasout 命令来生成基于文本的报告。topas 在处理其不足方面进行了大量的工作，但大多数管理员可能希望使用其他实用工具——如 nmon。

nmon

所有性能工具中，我最喜欢 nmon（不是 IBM“正式”支持的工具）。从 nmon 收集的数据（请参见图 3）可从屏幕查看，也可以通过通常从 cron 运行的报告查看。按照其创建者 Nigel Griffiths 的说法，“如果一个免费工具能够提供所需要的所有东西，为什么还要使用五个或六个工具？”

图 3. nmon 示例输出

务必注意，与已经讨论的一些其他工具不同，nmon 也可以在 Linux® 上使用，这可切实地帮助 Linux 赢得遇到性能问题的 POWER 用户群。nmon 最吸引管理员的是，不仅拥有非常高效的前端监视器（如图 3 中所示，管理员可以动态调用），而且提供了将数据捕获到文本文件进行图形报告的功能，因为输出是 .csv（电子表格）格式（请参见图 4）。事实上，运行 nmon 会话一段时间之后，可以实际看到以 Excel 电子表格形式良好呈现的表格，可以将此表格提交给高层管理人员或其他技术团队以进行分析。而且，与 topas 不同，我从来没有看到与此实用工具关联的任何性能类型开销。

接下来让我们看一个简单的任务。首先让我们告知 nmon 创建文件，对运行进行命名，并在 180 个时间间隔内每 30 秒进行一次数据收集（共计 1.5 个小时）：

# nmon -f -t -r test2 -s 30 -c 180
                        

 

 

完成此工作，对文件进行排序，如清单 6 中所示。

清单 6. 对文件进行排序

                        # sort -A testsystem_yymmd_hhmm.nmon > testsystem_yymmdd.hhmm.csv
                        

 

完成后，将 .csv 文件通过 FTP 上传到工作站，启动 nmon 分析器电子表格（确保启用了宏），然后单击 analyze nmon data（请参见图 4）。

图 4. nmon 分析器输出

nmon 分析器是一个非常不错的工具，是由 Stephen Atkins 编写的，能从 Excel 电子表格以图形表示数据（CPU、内存、网络或 I/O）。或许使其不能成为企业类型的工具的唯一缺陷就是，它缺乏同时在大量 LPAR 上收集统计数据的能力，因为它不是数据库（其设计也没有考虑成为数据库）。而这正是 Ganglia（请参见参考资料中提供的链接）能提供帮助的地方，该工具的设计思想实际上得益于 Nigel Griffiths，因为此工具能够集成 nmon 分析。

总结

本系列的第 2 部分对很多工具和实用程序进行了深入分析，可以将这些工具和实用程序用于捕获和分析运行 AIX 的 System p 服务器的性能数据。其中一些命令从 UNIX 推出之时就有了。其中很多命令用于 AIX，其他的则是不受支持的 IBM 实用工具，但大多数 AIX 管理员都在使用所有这些工具。无论最喜欢哪个工具，都需要使用其中一个来即时查看性能活动，而使用另一个工具来捕获用于进行基于历史的性能优化和趋势及容量规划分析的数据。有些工具能够同时进行这两项工作（如 nmon），但大部分都更为适合进行其中某一项工作。我建议您要对这些工具进行试验，不仅要找到最适合您的工具，还要找到能够为其他人员(不是能够理解无休止的 vmstat 显示信息的系统管理员)提供有价值信息的工具。