分类：
2009-08-04 11:23:15
内存子系统中最重要的优化部分并不涉及到实际的优化工作。在对您的系统进行优化之前，必须弄清楚主机系统的实际运行情况。要做到这一点，AIX? 管理员必须知道应该使用何种工具，以及如何对他或她将要捕获的数据进行分析。再次说明近期发表的一些其他优化文章中所介绍的内容，您在对系统进行正确地优化之前，必须首先监视主机，无论它是在逻辑分区 (LPAR) 运行还是在自己的物理服务器上运行。您可以使用许多命令来捕获和分析数据，所以您需要了解这些命令，以及其中的哪个命令最适合于将要进行的工作。在捕获了相关的数据之后，您需要对结果进行分析。有些问题乍看起来像是一个中央处理单元 (CPU) 的问题，而经过分析之后，可以正确地诊断为内存或 I/O 问题，前提是您使用了合适的工具捕获数据，并且知道如何进行分析工作。仅当正确地完成了这些工作之后，您才可以考虑对系统进行实际的更改。如果医生不了解您的病史和目前的症状，就无法诊治疾病，同样地，您也需要在优化子系统之前对其进行诊断。如果在出现 CPU 或者 I/O 瓶颈的情况下，对内存子系统进行优化，这将是毫无帮助的，甚至可能会影响主机的正常运行。
本文将帮助您了解正确地实施诊断工作的重要性。您将看到，性能优化并不仅仅只是进行实际的优化工作。在您将要学习的工具中，有一些是通用的监视工具，所有版本的 UNIX 都提供了这些工具，另外还有一些工具是专门为 AIX 编写的。有些工具为 AIX Version 5.3 进行了优化，同时还专门为 AIX 5.3 系统开发了一些新的工具。
生成基准数据是非常重要的，这一点无论重申多少次都不为过。不要等到用户开始抱怨糟糕的性能时，才开始监视您的系统。应该在将服务器投入生产环境中后，尽快地捕获其中的数据。如果您做到了这一点，那么您就可以积极主动地进行优化工作，其目标是在用户指出存在的问题之前找到它。如果您不了解系统正常运行时的相关数据，那么就无法确定所查看的数据是否表示存在性能问题。所有这些都是适当的性能优化方法中的一部分，有效地捕获数据，并正确地分析其结果和趋势。让我们来进行仔细地研究。
1.2.1UNIX 通用的内存监视
在这个部分中，我为在所有 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 工具的使用。
1.2.2 特定的 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，您就可以找出大量消耗内存资源的位置。
让我们使用一种对用户来说更加友好的工具，topas。topas 是一种非常优秀的小型性能监视工具，它可以用于许多目的（请参见 图 1）。
图 1. topas 工具
正如您所看到的，运行 topas 将为您提供一个有关进程信息、CPU、I/O 和 VMM 活动的列表。从这个列表中，您可以看到该系统仅使用了很少的分页空间。我常常使用这个命令快速地进行故障排除，特别是当我希望在屏幕上显示比 vmstat 更详细的内容时。我将 topas 看作是 vmstat 的图形化版本。在经过改进之后，现在它可以捕获数据以进行历史分析。
procmon 命令又如何呢？它在 AIX Version 5.3 中首次引入，不仅可以提供整体 CPU 性能统计，还允许您对实际运行的进程进行相应的操作。您可能已经了解，可以动态地对一个进程使用
kill 或者 renice 命令，但我敢打赌，您肯定不清楚如何深入地研究有关内存的内容。
尽管我认为人们通常使用这个工具进行 CPU 分析，但是它也为 svmon 提供了很好的挂钩，以便在紧要关头为您提供帮助。这个视图可以为从 procmon 中使用 svmon 实用工具设置相关的选项，它允许您以一种更合适的格式提取信息（请参见图 2）。
图 2. 为从 procmon 中使用 svmon 实用工具设置选项
您还可以将 procmon 数据导出到一个文件，这使得它成为一种优秀的数据收集工具。
在所有的性能工具中，我最喜欢的是一种不受支持的 IBM 工具，名为 nmon。它在某些方面与 topas 类似，nmon 收集到的数据可以显示在屏幕上（类似于 topas）或者通过报告提供（您可以捕获相关的信息以进行趋势研究和分析）。这个工具提供了一些其他工具所没有的功能，它可以在 Microsoft® Excel 电子表格中显示美观的图表，可以将其交给高级管理人员或者其他技术团队进行更深入地分析。可以使用另一种不受支持的工具，名为 nmon analyzer，它为 nmon 提供了相应的挂钩。图 3 显示了 nmon 分析结果的一个示例。
图 3. nmon 分析输出
在使用这个工具的过程中，您将看到 nmon 所提供的许多不同类型的视图，这些视图可以提供所有关于 CPU、I/O 和内存的使用信息。
总结
在本文中，您了解了可用于捕获数据以进行内存分析的各种工具。您还学习了如何对存在性能问题的系统进行故障排除，您可以对虚拟内存进行控制。优化工作实际上只是适当的优化方法中的一小部分，对于这一点，重申多少次都不为过。如果不能够捕获数据并仔细地、正确地分析您的系统，那么您所能做的工作就好像是一名医生根本不对患者进行检查就胡乱地使用抗生素药物。
您可以使用许多不同类型的性能监视工具。有些工具可以从命令行中运行，以便快速地检查系统的运行情况。有些工具更适合于进行长期的趋势研究和分析。有些工具甚至可以为您提供图形格式的数据，可以将这些数据交给非技术方面的工作人员。无论您使用哪种工具，都还必须仔细地了解您所查看的信息的真正含义。不要只根据少量的数据样本，就急于得出结论。另外，不要仅依赖于某一种工具。为了证实您的结论，在进行分析时，您应该至少使用两种不同的工具。我还简要地介绍了优化方法和建立系统正常运行时的基准数据的重要性。在您检查数据并实施优化之后，您必须继续捕获数据，并分析所作更改的结果。而且，您应该一次只进行一处更改，这样才能够真正地确定每项更改的效果.
