性能监控各个工具监控.docx

性能监控各个工具监控.docx

《性能监控各个工具监控.docx》由会员分享，可在线阅读，更多相关《性能监控各个工具监控.docx（13页珍藏版）》请在冰点文库上搜索。

性能监控各个工具监控

IBMAIX系统性能分析

2010-08-1406:

24

作为AIX管理员，最重要的职责之一就是优化您的系统。

如果不首先监视系统并分析结果，就不能进行优化。

对于长期趋势和短期（接下来数小时内必须完成的工作）问题均是如此。

虽然可以使用特定工具仅对CPU进行分析，但对于给定环境，可能要使用在系统上寻找所有可能瓶颈的工具。

正如您可能已经知道的，CPU是系统中最快的组件。

如果您的CPU是瓶颈，将会对整个系统的性能造成影响。

在我介绍这些工具时，请您注意以下命令已在AIX5.3中进行了增强，允许工具使用AdvancedPowerVirtualization报告有关共享分区的准确统计数据：

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

#vmstat1

Systemconfiguration:

lcpu=2mem=3920MB

kthr    memory                page              faults          cpu    

-----  -----------    ------------------------------------  -----------

r  b    avm  fre    re  pi  po  fr  sr  cy  in  sy  cs  ussyidwa

0  0  229367332745  0  0  0  0    0  0  3  198  69    0  099  0

0  0  229367332745  0  0  0  0    0  0  3  33  66    0  099  0

0  0  229367332745  0  0  0  0    0  0  2  33  68    0  099  0

0  0  229367332745  0  0  0  0    0  0  80  306100    0  197  1

0  0  229367332745  0  0  0  0    0  0  1  20  68    0  099  0

0  0  229367332745  0  0  0  0    0  0  2  36  64    0  099  0

0  0  229367332745  0  0  0  0    0  0  2  33  66    0  099  0

0  0  229367332745  0  0  0  0    0  0  2  21  66    0  099  0

0  0  229367332745  0  0  0  0    0  0  1  237  64    0  099  0

0  0  229367332745  0  0  0  0    0  0  2  19  66    0  099  0

0  0  229367332745  0  0  0  0    0  0  6  37  76    0  099  0

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

∙r——在所选择的任意采样间隔期间的平均可运行内核线程数。

∙b——采样期间在虚拟内存中等待队列的平均内核线程数。

r应该始终高于b；如果不是，通常意味着遇到了CPU瓶颈。

∙fre——可用内存列表的大小。

如果此数量并不小，不要太过担心。

更为重要的是，在此数量小的情况下确定是否进行了任何分页操作。

∙pi——从页面空间读取的页面。

∙po——写入页面空间的页面。

∙CPU部分：

ous

osy

oid

owa

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

∙us——用户时间

∙sy——系统时间

∙id——空闲时间

∙wa——等待I/O

显然，此系统没有瓶颈。

如何确定的呢？

让我们看一看vmstat输出中要分析的更为重要的字段。

尽管此系统运行的是AIX5.3，将不会看到物理处理器的数量或使用的可用容量的百分比，因为它不在微分区环境中运行。

如果在微分区环境中运行，将看到这些额外的字段，因为对vmstat进行了增强，可以在虚拟环境和微分区环境工作。

如果您的us和sys条目都平均高于80%，很可能遇到了CPU瓶颈。

如果上升到了100%，您的系统就真的太繁忙。

如果这些数字很小，但wa（等待I/O）很高（通常大于30），这意味着系统上存在I/O问题，从而导致CPU不能到达其最佳工作状态。

如果sy时间比us时间长，这意味着您的系统处理数字的时间比实际处理内核数据的时间短。

这也不好。

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

那用户为什么会对系统抱怨呢？

因为系统真的让用户感觉到运行得很慢。

直到我确定了没有系统问题，而且相邻的同事没有出现问题，我才确定了问题的根源。

因此，我让他重新启动PC，从而获得干净的客户机系统。

显然，某个正在运行的东西造成了PC客户机故障。

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

清单2.再次运行vmstat

#vmstat1

Systemconfiguration:

lcpu=2mem=3920MB

kthr    memory              page              faults        cpu    

----------------------------------------------------  -----------

r  b  avm  fre  re  pi  po  fr  sr  cy  in  sy  cs  ussyidwa

9  0  4200  2746  0  0  0  0    0  0  3  198  69  7030  0  0    0

4  7  4200  2746  0  0  0  0    0  0  3  33  66  6731  2  0    0

2  6  4200  2746  0  0  0  0    0  0  2  33  68  6534  1  0    0

3  9  4200  2746  0  0  0  0    0  0  80  306100  8020  0  1    0

2  7  4200  2746  0  0  0  0    0  0  1  20  68  8020  0  0    0

这又说明什么呢？

显然，此系统处于CPUBound状态。

没有进行分页，也没有任何I/O问题。

有大量可运行线程，但没有足够的CPU周期来处理需要完成的工作。

我得出这个结论花了多长时间？

仅仅五秒钟。

也可以尝试使用其他实用工具来进行此工作。

使用sar

下一个命令sar是UNIXSystemActivityReporting工具（属于bos.acct文件集）。

此命令似乎已经成为了UNIX世界中永远存在的一员。

此命令实际上就是将选择作为其标志的积累活动的内容写入到标准输出。

例如，以下命令使用-u标志报告CPU统计数据。

对于vmstat，如果在虚拟环境中使用共享分区，将会报告两个其他信息列：

physc和entc，这两个列分别定义分区所使用的物理处理器的数量以及所使用的可用容量。

我在没有用户的情况下在系统上运行此命令（请参见清单3）。

除非有批处理作业在运行，否则就不会看到大量的活动。

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

#sar-u15（orsar15）

AIXtest0135    03/18/07

Systemconfiguration:

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的一个优势是，它允许捕获日常信息和运行关于此信息的报告（不用自己撰写脚本来进行此工作）。

它通过使用名为SystemActivityDataCollector的进程实现此工作，此进程实际是sar命令的一个后端进程。

在已启用的情况下，它通常通过cron（在缺省AIX分区上，通常会发现将其注释掉了）以二进制格式定期收集数据。

AIX特定的CPU监视工具

接下来我们讨论特定于AIX的命令。

编写这些命令的目的是为了让管理员在分区环境中监视系统。

这些命令在使用AdvancedPOWERVirtualization功能（如共享处理器和微分区）时尤为有用。

使用lparstat

当用户首次报告系统运行缓慢时，我决定启动lparstat。

lparstat命令用于报告逻辑分区（LogicalPartition，LPAR）信息和相关统计数据。

在AIX5LV5.3中，lparstat命令将显示关于很多POWERHypervisor调用的Hypervisor统计数据。

lparstat命令是一个相对较新的命令，通常用于在共享处理器分区环境中提供帮助。

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

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

#lparstat-h15

Systemconfiguration:

type=Dedicatedmode=Cappedsmt=Onlcpu=4mem=3920

%user  %sys  %wait  %idle  %hypvhcalls

-----  ----  -----  -----  -----------

  0.0  0.7    0.0  99.3  44.45933918

  0.4  0.3    0.0  99.3  44.95898086

  0.0  0.1    0.0  99.9  45.15930473

  0.0  0.1    0.0  99.9  44.65931287

  0.0  0.1    0.0  99.9  44.65931274

正如您看到的，从某种程度而言，上面所生成的输出与sar命令相似。

请注意，对于在专用环境或共享Capped环境中运行AIX5.2或AIX5.3的分区，总体CPU使用率基于user、sys、wait和idle值。

在采用Uncapped模式运行的AIX5.3分区中，使用率应该基于可用容量百分比。

mpstat

我经常使用的另一个命令是mpstat命令（请参见清单5），该命令属于bos.acct文件集。

这是专门为AIX5.3创建的工具（与lparstat不同），用于显示分区系统上所有逻辑CUP的总体性能值。

运行mpstat命令时，将显示两个部分的统计数据。

第一部分显示系统配置，在该命令开始执行以及对系统配置进行了修改时，将显示这部分信息。

第二部分显示使用率统计数据，此数据将以用户指定的时间为间隔显示。

清单5.运行mpstat

#mpstat11

Systemconfiguration:

lcpu=2ent=2.0

cpuminmajmpcintcsicsrqmiglpasysc          ussywaid  pc  %ec  lcs

0    0  0  0  1648340  01  100  17            0  001000.178.3  113

1    0  0  0  102  1  1  10  10038304536634  0  00100  .8341.6      

我喜欢使用mpstat命令，因为它会采用非常清晰的格式报告所收集的分区上的每个逻辑CPU的信息。

通过使用-s选项，甚至还能够看到同步多线程（SimultaneousMultiThreading，SMT）线程使用率。

lparstat和mpstat命令的缺点在于，二者都需要编写脚本和其他工具来处理数据格式和图形输出。

实际上，您需要编写自己的shell脚本。

尽管大部分管理员喜欢使用脚本，但他们却不愿意做重复工作。

如果已经有了相应的工具来帮助您分析历史数据，编写自己的实用工具就不太明智了。

GUI工具

接下来我们将了解一些实用工具，通过这些工具能以图形查看分析，还能对历史数据进行分析。

尽管完全了解这些工具需要一定的时间，但这些工具比我们已经了解的命令行工具要更为灵活。

procmon

接下来我们讨论procmon（请参见图1）。

此实用工具（在AIX5.3中发布）不仅提供总体性能统计数据，还允许对实际运行的处理器进行操作。

它允许管理员动态地结束进程或恢复进程。

还可以将procmon数据导出到文件中，这就使其成为了一个不错的数据收集工具。

procmon实际上作为性能Workbench的插件运行，此Workbench可通过使用perfwb（位于/usr/bin中）命令（属于bos.perf.gtools.perfwb文件集）启动。

图1.procmon输出

我之所以喜欢procmon，是因为它允许对进程进行操作，而这可以提高系统的性能。

虽然这个工具也有局限性，但我强烈建议您下载并使用此工具（我发现大多数管理员都不习惯使用此工具）。

topas

应该注意的另一个工具是topas。

老实说，尽管在AIX5.3中有了大幅度提升，但我从来没有遇到过太多的topas（属于bos.perf.tools文件集）迷。

在进行这些更改前，它并不能捕获历史数据，也未针对在共享分区环境中使用而进行增强。

通过这些更改，您可以从多个分区收集性能数据，切实地简化了topas作为性能管理和容量规划工具的功能。

topas的外观（请参见图2）与top和monitor（在其他UNIX变体中使用）非常相似。

topas是在屏幕上以基于文本的GUI格式显示所有信息的一款实用工具。

采用其缺省模式时，会显示主机名、刷新间隔和CPU、内存及I/O信息的综合情况。

图2.topas显示

有些新功能还包括允许在虚拟I/O服务器（VirtualI/OServer，VIOServer）上运行topas。

为此，请使用以下命令：

#topas-cecdisp

在LPAR上，要运行：

topas-C

考虑到在5.3TL4中引入了性能监视功能，topas使用了从inittab自动启动的守护进程xmwlm。

在AIX5.3的TL_5中，缺省会保留七天的数据，并会记录几乎所有的topas数据，除进程和工作负载管理器（WorkloadManager，WLM）信息外，其中的其他数据会以交互方式显示。

它使用topasout命令来生成基于文本的报告。

topas在处理其不足方面进行了大量的工作，但大多数管理员可能希望使用其他实用工具——如nmon。

nmon

所有性能工具中，我最喜欢nmon（不是IBM“正式”支持的工具）。

从nmon收集的数据（请参见图3）可从屏幕查看，也可以通过通常从cron运行的报告查看。

按照其创建者NigelGriffiths的说法，“如果一个免费工具能够提供所需要的所有东西，为什么还要使用五个或六个工具？

”

图3.nmon示例输出

务必注意，与已经讨论的一些其他工具不同，nmon也可以在Linux®上使用，这可切实地帮助Linux赢得遇到性能问题的POWER用户群。

nmon最吸引管理员的是，不仅拥有非常高效的前端监视器（如图3中所示，管理员可以动态调用），而且提供了将数据捕获到文本文件进行图形报告的功能，因为输出是.csv（电子表格）格式（请参见图4）。

事实上，运行nmon会话一段时间之后，可以实际看到以Excel电子表格形式良好呈现的表格，可以将此表格提交给高层管理人员或其他技术团队以进行分析。

而且，与topas不同，我从来没有看到与此实用工具关联的任何性能类型开销。

接下来让我们看一个简单的任务。

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

#nmon-f-t-rtest2-s30-c180

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

清单6.对文件进行排序

#sort-Atestsystem_yymmd_hhmm.nmon>testsystem_yymmdd.hhmm.csv

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

图4.nmon分析器输出

nmon分析器是一个非常不错的工具，是由StephenAtkins编写的，能从Excel电子表格以图形表示数据（CPU、内存、网络或I/O）。

或许使其不能成为企业类型的工具的唯一缺陷就是，它缺乏同时在大量LPAR上收集统计数据的能力，因为它不是数据库（其设计也没有考虑成为数据库）。

而这正是Ganglia（请参见参考资料中提供的链接）能提供帮助的地方，该工具的设计思想实际上得益于NigelGriffiths，因为此工具能够集成nmon分析。

总结

本系列的第2部分对很多工具和实用程序进行了深入分析，可以将这些工具和实用程序用于捕获和分析运行AIX的Systemp服务器的性能数据。

其中一些命令从UNIX推出之时就有了。

其中很多命令用于AIX，其他的则是不受支持的IBM实用工具，但大多数AIX管理员都在使用所有这些工具。

无论最喜欢哪个工具，都需要使用其中一个来即时查看性能活动，而使用另一个工具来捕获用于进行基于历史的性能优化和趋势及容量规划分析的数据。

有些工具能够同时进行这两项工作（如nmon），但大部分都更为适合进行其中某一项工作。

我建议您要对这些工具进行试验，不仅要找到最适合您的工具，还要找到能够为其他人员（不是能够理解无休止的vmstat显示信息的系统管理员）提供有价值信息的工具