AIX内存性能优化和监视

使用 ps、sar、svmon 和 vmstat 监视内存的使用，并分析所得到的结果。这个由三篇文章组成的系列重点关注于在运行 AIX 的 IBM System p 服务器上进行内存管理和优化的各个方面。第 1 部分提供了关于 AIX 中内存的概述，包括对虚拟内存和虚拟内存管理器 (VMM) 的介绍。它还深入地分析了各种优化参数，并对 AIX Version 5.3 中内存管理方面的改进内容进行了介绍。第 2 部分重点关注于内存子系统监视的详细内容，并介绍了如何分析所得到的结果。第 3 部分主要介绍交换空间，以及如何最好地优化 VMM 设置，以提供最优的交换空间配置和性能。在本系列文章中，我还将介绍一些内存性能优化和监视方面的最佳实践。

在 IBM Bluemix 云平台上开发并部署您的下一个应用。

引言

内存子系统中最重要的优化部分并不涉及到实际的优化工作。在对您的系统进行优化之前，必须弄清楚主机系统的实际运行情况。要做到这一点，AIX 管理员必须知道应该使用何种工具，以及如何对他或她将要捕获的数据进行分析。再次说明近期发表的一些其他优化文章（请参见 参考资料）中所介绍的内容，您在对系统进行正确地优化之前，必须首先监视主机，无论它是在逻辑分区 (LPAR) 运行还是在自己的物理服务器上运行。您可以使用许多命令来捕获和分析数据，所以您需要了解这些命令，以及其中的哪个命令最适合于将要进行的工作。在捕获了相关的数据之后，您需要对结果进行分析。有些问题乍看起来像是一个中央处理单元 (CPU) 的问题，而经过分析之后，可以正确地诊断为内存或 I/O 问题，前提是您使用了合适的工具捕获数据 ，并且知道如何进行分析工作。仅当正确地完成了这些工作之后，您才可以考虑对系统进行实际的更改。如果医生不了解您的病史和目前的症状，就无法诊治疾病，同样地，您也需要在优化子系统之前对其进行诊断。如果在出现 CPU 或者 I/O 瓶颈的情况下，对内存子系统进行优化，这将是毫无帮助的，甚至可能会影响主机的正常运行。

本文将帮助您了解正确地实施诊断工作的重要性。您将看到，性能优化并不仅仅只是进行实际的优化工作。在您将要学习的工具中，有一些是通用的监视工具，所有版本的 UNIX 都提供了这些工具，另外还有一些工具是专门为 AIX 编写的。有些工具为 AIX Version 5.3 进行了优化，同时还专门为 AIX 5.3 系统开发了一些新的工具。

生成基准数据是非常重要的，这一点无论重申多少次都不为过。不要等到用户开始抱怨糟糕的性能时，才开始监视您的系统。应该在将服务器投入生产环境中后，尽快地捕获其中的数据。如果您做到了这一点，那么您就可以积极主动地进行优化工作，其目标是在用户指出存在的问题之前找到它。如果您不了解系统正常运行时的相关数据，那么就无法确定所查看的数据是否表示存在性能问题。所有这些都是适当的性能优化方法中的一部分，有效地捕获数据，并正确地分析其结果和趋势。让我们来进行仔细地研究。

UNIX 通用的内存监视

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

大多数管理员都不善于使用 ps 命令对可能的内存瓶颈进行故障排除。事实上，许多 UNIX 管理员甚至不知道可以使用 ps 帮助确定内存问题的原因。ps 最常用的功能是查看系统中运行的进程（请参见清单 1）。

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

# ps -ef | more
  UID   PID  PPID   C    STIME    TTY  TIME CMD
    root     1     0   0   May 03      -  0:03 /etc/init
    root 11244 19154   0                  0:00 
    root 11384     1   0   May 03      -  0:00 /usr/lib/errdemon
    root 12434 16618   0   May 03      -  0:29 /usr/opt/ifor/bin/i4llmd -b -n wc
clwts -l /var/ifor/llmlg
    root 13218 16618   0   May 03      -  0:00 /usr/sbin/rsct/bin/IBM.AuditRMd
    root 13440     1   0   May 03      -  0:00 /usr/ccs/bin/shlap
    root 13690 13954   0   May 03      -  0:00 dtlogin <:0>        -daemon
    root 13954     1   0   May 03      -  0:00 /usr/dt/bin/dtlogin -daemon

正如您所看到的，上面的示例中并没有提供很详细的信息来帮助您确定内存瓶颈。清单 2 中的命令向您显示了系统中每个活动进程的内存使用情况，并以一种恰当的方式进行了排序。其中按照旧式 Berkeley Software Distribution (BSD) 的方式使用了 ps，不包含短横线。我喜欢这个命令的原因在于，您不需要调用任何 GUI 类型的工具，就可以快速地了解内存方面的情况（请参见清单 2）。

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

.
# ps gv | head -n 1; ps gv | egrep -v "RSS" | sort +6b -7 -n -r
  PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
 15256      - A    64:15  755  2572  2888    xx  2356   316  0.9  0.0 /usr/lpp/
 22752      - A     0:08  261  1960  1980 32768   465    20  0.0  0.0 dtwm
 14654      - A     0:00  324  1932  1932    xx   198     0  0.0  0.0 /usr/sbin
 20700      - A     0:07  271  1868  1896 32768    95    28  0.0  0.0 /usr/dt/b
 20444      - A     0:03  203  1736  1824 32768   551    88  0.0  0.0 dtfile
 17602      - A     0:00  274   948  1644 32768   817   696  0.0  0.0 sendmail:
 13218      - A     0:00   74  1620  1620    xx   116     0  0.0  0.0 /usr/sbin

让我们先来看看这些信息所表示的含义。

• RSS——每个进程的文本和数据段的 RAM 使用量。PID 为 15256 的进程使用了 2888k。
• %MEM——RSS / Total RAM 的实际用量。监视 %MEM 使用达到百分之四十到七十的进程。
• TRS——文本段的 RAM 使用量，单位为 KB。
• SIZE——为这个进程（文本和数据）分配的分页空间的实际大小。

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

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

# vmstat 1 4

System Configuration: lcpu=4 mem=4096MB
kthr     memory             page              faults        cpu
----- ----------- ------------------------ ------------ -----------
 r  b   avm   fre  re   pi  po  fr   sr    cy  in   sy  cs  us sy id wa
 1  2 136583  127    0   4   57  44   92    0 345 2223 605  30 40 29 1
 2  7 136587  118    0   2  230   0   245   0 329 3451 526  20 37 10 33
 1  6 136587  157    0   3   67   0   678   0 334 3304 536  25 32 20 23
 3  8 136587  111    0   5   61   0   693   0 329 3341 511  19 26 35 20

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

内存数据：

• avm——您所使用的活动虚拟内存量（单位为 4k 大小的页面），不包括文件页面。
• fre——内存空闲列表的大小。在大多数情况下，我并不担心这个值什么时候变得很小，因为 AIX 总是会充分地使用内存，并且不会像您希望的那样尽早地释放内存。这个设置由 vmo 命令的 minfree 参数来确定。归根结底，分页的信息更加重要。
• pi——从分页空间调入的页面。
• po——调出到分页空间的页面。

CPU 和 I/O：

• r——在您指定的时间间隔内，可运行内核线程的平均数量。
• b——在您指定的时间间隔内，位于虚拟内存等待队列中的内核线程的平均数量。如果 r 不大于 b，通常是 CPU 问题的症状，这可能是由于 I/O 或者内存瓶颈造成的。
• us——用户时间。
• sy——系统时间。
• id——空闲时间。
• wa——等待 I/O。

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

现在，再回到输出。出现了什么问题呢？实际上，有好几处问题。初看起来，您可能认为出现了 CPU 瓶颈，因为系统工作得非常辛苦，几乎没有什么空闲时间。如果您仔细地观察，那么将会发现，除了 CPU 忙碌工作之外，还存在其他的问题，例如分页。从 po 可以看出，出现了大量的页面调出，这种情况通常会在实际内存缺乏的时候出现。在输出结果中，甚至空闲列表也降到非常低的程度。其原因可能因为您的空闲列表 (fre) 比 minfree 的阈值（使用 vmo 进行设定的）要低一些。I/O 方面出现了什么问题呢？当您发现阻塞的进程或者等待 I/O 的值 (wa) 很高时，这通常表示出现了实际的 I/O 问题，可能是等待文件访问、或者与因为系统缺少内存而引起的分页相关的 I/O 状况。在这个示例中，看起来是后面这种情况。您碰到了 VMM 问题，而这些问题可能导致了阻塞的进程和等待 I/O 的状况。通过优化内存参数、或者执行动态的 LPAR (DLPAR) 操作并向 LPAR 添加更多的 RAM，您可以解决这个问题。

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

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

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

# sar -r 1 5
System Configuration: lcpu=4 mem=4096MB

06:18:05   slots  cycle/s  fault/s  odio/s
06:18:06 1048052    0.00    387.25   0.00
06:18:07 1048052    0.00    112.97   0.00
06:18:08 1048052    0.00    45.00   79.21
06:18:09 1048052    0.00    216.00    0.00
06:18:10 1048052    0.00    8.00      0.00

Average  1048052        0      79      16

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

• cycle/s——报告每秒的页面置换周期数。
• fault/s——提供每秒的缺页次数。
• Slots——提供分页空间中空闲页面的数目。
• odio/s——提供每秒的非分页磁盘 I/O 次数。

在这个示例中，您可以看到每秒钟有许多次的缺页，但是其他的值并不大。您还可以看到，分页空间中有 1048052 个 4k 的页面可用，总计约 4GB。下面，让我们再来深入地研究特定 AIX 工具的使用。

特定的 AIX 内存监视

在这个部分中，我提供了关于可用的特定 AIX 工具的概述，包括 svmon、procmon、topas 和 nmon。其中的大多数工具都允许您快速地进行故障排除，并获取相关的数据以便进行历史趋势研究和分析。

svmon 是一种分析实用工具。它专门针对于 VMM。它可以提供许多信息，包括所使用的实际、虚拟和分页空间内存。-G 标志可以为主机中的内存使用情况提供全局的视图（请参见清单 5）。

清单 5. 使用带 -G 标志的 svmon

# svmon -G
               size      inuse       free        pin    virtual
memory      1048576    1048416        160      79327     137750
pg space    1048576        524

               work       pers       clnt      lpage
pin           79327          0          0          0
in use       137764     910652          0          0

其中的 size 列报告了 RAM 的大小，单位是大小为 4k 的页面。其中的 inuse 列报告了进程所使用的 RAM 中的页面数，加上属于一个已终止的进程但仍位于 RAM 中的持久页面的数目。其中的 free 列报告了空闲列表中页面的数目。其中的 pin 列报告了物理内存 (RAM) 中固定的页面数。固定的页面不能被调出。

paging space 列报告了分页空间的实际使用情况（单位是大小为 4k 的页面）。重要的是，应该清楚这个结果与 vmstat 所报告的结果之间的区别。vmstat 中的 avm 列显示了访问的所有虚拟内存，即使它没有被调出。我还习惯查看工作和持久页面的数目。这些参数显示了 RAM 中工作和持久页面的数目。这个内容为什么非常重要呢？也许您还记得第 1 部分中的内容，我曾介绍了工作和持久存储之间的区别。当您的进程对计算信息进行处理时，将使用到计算内存。它们使用工作段，而这些工作段是临时的（暂时的），并且当进程终止或者页面被替换时，这些工作段将不复存在。文件内存使用持久段，并在磁盘上具有持久的存储位置。数据文件或者可执行程序通常都映射为持久段，而不是工作段。在可以选择的情况下，您更希望将文件内存调出到磁盘，而不是计算内存。在这种情况下，与文件内存相比，计算内存更有可能被调出。也许，对 vmo 参数稍作优化就可以极大提高系统的性能。svmon 的另一个有价值的特性是，您可以显示给定进程的内存统计信息。清单 6 提供了一个示例。

清单 6. 使用 svmon 显示给定进程的内存统计信息

# svmon -P | grep -p 15256
-------------------------------------------------------------------------------
     Pid Command          Inuse      Pin     Pgsp  Virtual 64-bit Mthrd LPage
   15256 X                12102     3221        0    12022      N     N     N

从这个示例中，您可以确定该进程并没有使用分页空间。使用前面介绍过的 ps 命令，再加上 svmon，您就可以找出大量消耗内存资源的位置。