【原创】使用Nmon_Analyzer处理较大nmon文件的方法

1 编写目的

进行性能测试时，测试服务器使用的操做系统是Linux或Unix时，咱们通常会使用Nmon工具进行操做系统资源监控数据的收集。Nmon工具是一款很是优秀的性能监控和分析工具，它可以实时地收集系统资源的使用状况，而且能输出结果到文件中，而后经过Nmon_analyzer工具生成.xls格式的数据文件和图形化的监测结果。经过图形化界面分析，得出系统在一段时间内资源占用的变化趋势，有了这个分析结果就能够帮助咱们更好定位性能问题。

可是在实际的使用过程当中，特别是长时间稳定性测试时，当单个结果的nmon数据文件较大时，Nmon_analyzer就没法生成完整的分析结果，也没法造成图形化的报告，本文针对这类问题，介绍一种使用Nmon_analyzer分析较大的Nmon结果文件的方法。

文中的绝大部份内容来源于本人的工做实践，全部内容都通过实际验证，但不免有疏漏之处，若有疑问，请你们不吝赐教。

注：Nmon系列工具的使用方法这里不作介绍，你们能够参考其余相关的使用教程。

2 Nmon系列工具介绍

2.1 Nmon工具

Nmon是Linux或Unix操做系统下经常使用的资源监控工具，可以实时的监控操做系统的各类资源的使用状况，包括CPU占用率、内存使用状况、网络I/O速度、服务器硬件信息和资源等信息。目前支持Redhat、AIX、Solaris等各类主流的操做系统。

因为最终的结果分析文件要在Windows上生成，而Nmon_analyzer工具仅识别以.csv和.nmon做为后缀名的文件,因此通常用.nmon做为Nmon文件的后缀名。

2.2 Nmon_analyzer工具

Nmon工具在监控机器上生成的结果文件，须要使用Nmon_analyzer工具进行解析。Nmon_analyzer工具是一个Excel文件，将.nmon结果文件导入后，会生成一个有多个sheet的Excel报告文件，内容包括图形化的监控报告、被监控服务器的硬件信息和整个监控时段的系统资源使用状况。

3 处理较大的.nmon文件

3.1 .nmon文件介绍

Nmon工具生成的监控数据是一种有固定格式的数据文件。它的内容包括两部分：一部分是被监控服务器的硬件和操做系统信息，包括CPU的型号、主频的大小，内存和硬盘的大小等等，还包括了Nmon_analyzer分析生成的Excel文件的格式约束等信息，这里把Nmon数据文件的这部份内容叫作头文件，能够看出，头文件相对于Nmon_analyzer是一个标准和格式要求，Nmon_analyzer根据头文件的约束规则来解析.nmon的数据。

另外一部份内容就是具体的资源监控数据，这部分数据是随着时间不断变化的，变化的间隔是在执行监控命令时经过命令行参数设置的，Nmon_analyzer使用这些数据生成最终的报告内容，也就是咱们所关心的CPU平均占用率、内存使用状况等信息。

3.2 较大的.nmon文件会引发什么问题

当Nmon_analyzer工具处理较大的.nmon文件时，若是由于文件较大而没法解析，通常会出现以下的两类错误提示：

两种错误提示可能只出现一种，也可能两种前后都出现。当只出现第一种提示时，通常认为是资源不足；只出现第二种提示时，通常是因为使用的Nmon_analyser版本比较旧，没法支持生成单个Sheet超过65535行的文件，另外，Excel 2003之前(含2003)的版本也没法支持生成超过65535行的Sheet。而两种前后都出现的状况是先出现第一种提示，点击【肯定】后，又出现了第二种提示信息。

针对错误信息进行分析，第一种提示，很显然是可用资源不足，建议“少选择一些数据或关闭其余的应用程序”。那么针对第一种提示，本次分别使用2G、4G和8G内存的机器，大小相同的.nmon文件进行实验，问题依旧。针对第二种提示，咱们使用新版本的Nmon_analyser工具和2007版本以上的Excel软件进行测试，此时就会又出现第一种的错误提示。

经过上面的实验，能够初步判断出现错误的缘由是因为资源不足致使的。可是为何使用8G内存进行测试仍是没有解决问题呢？是因为8G内存仍是不够大吗？换成16G的内存再试试？那么测试7*24小时的稳定性生成更大的文件时，到底多大的内存才足够？

3.3 产生较大.nmon文件的缘由

下面介绍为何会产生比较大的.nmon文件。

按照实验室使用Nmon监控资源的通用命令，通常每3秒采集一次系统资源。这样，在进行长时间的稳定测试时，好比执行8小时以上的稳定性测试，生成的监控信息就比较多了，而且因为CPU监控是按照CPU的核数生成Sheet，因此CPU核数越多，生成的Sheet也会越多。虽然文件大小可能就几十兆(好比下面举例的文件只有18MB)，可是因为.nmon是一种相似.txt的纯文本格式，因此包含的数据量仍是至关惊人的。

3.4 分析问题

显然光靠加大内存是没法解决全部问题的。通常的操做系统在管理和分配内存时，会保留一部份内存做为操做系统自身管理所须要的内存，一般是系统内存的20%~40%左右，实际可供应用程序申请使用的内存是很是有限的，而且32位的应用程序理论上最大也只能管理并使用4G的内存，而咱们使用的Excel 软件和Nmon系列工具显然都是32位的，因此再大的内存也是没有意义的。

那么该如何解决问题呢？很容易想到的方法是使用64位的Excel软件和Nmon系列工具，发挥出大内存的优点。不过很惋惜的是，目前虽然已经有64位的OFFICE 2010，可是因为兼容性和稳定性的问题，Nmon_analyser工具没有提供64位的版本，移植Nmon_analyser工具中使用的大量的VBA代码的工做量是很是巨大的，因此暂时还没法使用这种方法。

那么就只剩一种方法了，按照错误提示的建议：“少选择一些数据”，即减少.nmon文件的大小。Nmon_analyser工具在解析结果文件时，会先把全部须要处理的文件一次性导入内存，因此减少导入文件的大小也是节省内存的一种手段，目前来讲是比较可行的解决方案。

3.5 解决问题

3.5.1 使用split命令

如何减少.nmon文件的大小呢？其实操做系统已经提供了颇有用的文件分割命令，即split。

split是Linux/Unix自带的系统命令，通常的使用语法以下：

split [-<行数>][-b <字节>][-C <字节>][-l <行数>][分割的文件名][输出的文件名]

参数：

-<行数>或-l <行数> 指定每多少行要切成一个小文件。

-b <字节> 指定每多少字节要切成一个小文件。支持单位m，k。

-C <字节> 与-b参数相似，但切割时尽可能维持每行的完整性。

下面以一个大小为18M左右的8hours.nmon文件为例，详细介绍如何使用split命令把它分割成Nmon_analyser工具能够解析的文件，而且最终合并成为一个完整的Excel报告。

首先登陆Linux系统，在8hours.nmon文件所在目录下，执行“split -l 100000 8hours.nmon 8hours.nmon”命令，生成的文件以下：

能够看到，18M大小的结果文件，分割成每一个文件10W行，总计生成5个子文件。分割的子文件个数不宜太多，子文件太多的话，合并时工做量比较大；子文件太少的话，单个子文件过大，Nmon_analyser仍是没法处理。

把生成的子文件拷贝到Windows系统下，将子文件导入Nmon_analyser工具进行解析，第一个文件8hours.nmonaa没有问题，能够成功生成报告，但从第二个开始报错，解析失败。使用UltraEdit或其余文本工具打开8hours.nmonaa和8hours.nmonab两个文件，比较它们的内容，发现第一个文件里面有完整的头文件：

第二个文件里面只有数据文件，没有头文件：

按照第3.1节的介绍，没有头文件的.nmon是没法被解析的，处理的方法也很简单，把头文件拷贝到除了第一个文件外的全部文件便可。须要注意的头文件的内容有哪些，咱们看一下第一个文件的内容：

从上图能够看到，从第1002行开始，已是具体的监控数据信息了，因此从第1行到1001行就是头文件的内容，将该内容拷贝到其余几个.nmon文件中，而后使用解析工具Nmon_anaylzer生成子报告。

打开生成的Excel报告文件，发现监控的各个时间点都变成没法识别的数字，以下图：

再次检查各个子文件的区别，发现因为以前把一个监控数据文件分割成了多个，因此每一个数据文件都不是完整的，虽然添加了头文件，可是除了第一个文件外，其余文件的起始时间多是在上一个子文件里的，因此就形成了子文件没法获取监控时间起点的问题。好比第一个结果文件最后的数据以下：

第二个结果文件最开始的数据以下图：

注意上图的第一行，只有监控数据，没有监控时间，这样在Nmon_analyser解析该文件时，因为没有监控的起始时间，致使后面的监控时间出现混乱，因此除了第一个子文件外，后面每一个子文件都须要添加监控的起始时间。方法是将前一个数据文件最后一次出现的时间数据直接拷贝到当前文件第一行(不包括头文件)便可。

全部的子文件都生成结果报告后，下面的工做就是合并各个报告，生成一个完整的监控结果报告。根据目前实验室性能测试报告的数据要求，仅进行CPU和内存数据的合并。

CPU数据的合并涉及SYS_SUMM和CPU_ALL两个sheet，首先按照数据产生的前后顺序，把全部子文件CPU_ALL的数据拷贝到第一个子文件的CPU_ALL，记录拷贝以后的数据总行数，本例中是3061行，同时计算各列的平均值和最大值(实际按照报告要求，只计算CPU%一列便可)，以下图：

SYS_SUMM中的CPU的AVG和MAX值即来自上图中的数据。下面介绍如何生成SYS_SUMM中的CPU坐标图，在拷贝全部CPU_ALL的数据到第一个子文件以后，查看SYS_SUMM中的CPU坐标图：

能够看到，横轴的时间没有变化，仍是第一个子文件的时段，须要根据CPU_ALL的数据进行调整，直接点击CPU曲线，能够看到sheet表格上方出现了CPU曲线的生成公式：

显然曲线的生成公式没有包含合并的CPU数据，因此须要修改公式，修改最大行数为合并后的行数，即3061行，修改后的公式以下：

=SERIES(CPU_ALL!$F$1,CPU_ALL!$A$2:$A$3061,CPU_ALL!$F$2:$F$3061,1)

生成的CPU曲线图以下：

能够看到，曲线图已经包含了全部的CPU监控数据，再修改Avg和Max的值为实际值，即完成了CPU监控数据的整合。

内存监控数据的合并比较简单，将全部的数据拷贝到第一个子文件中名为MEM的sheet中，而后计算Max、Min和Average的值便可。

3.5.2 使用文本编辑器

在实际的工做中，还有一种比较简单的替代split的方法。因为.nmon是一种类.txt格式的文件，因此可使用市面经常使用的txt编辑器直接打开进行分割和编辑。这里不用windows自带的txt工具打开是由于.nmon文件通常都比较大，打开比较慢，并且自带的txt工具编辑功能较差，不推荐使用，建议使用Ultraedit或Editplus等工具。

另外，之因此把split命令做为第一种解决问题的方法，是由于在外出工做时，客户的办公场所极可能限制外来U盘和外网的接入，因此若是测试机上未安装Ultraedit或Editplus等编辑工具，使用Linux/Unix自带的split命令便成了第一选择。

3.6 规避方法

遇到问题时，若是暂时没法解决，在之后的工做中尝试规避问题，也是解决问题的一种方式。在使用Nmon命令行收集系统资源时，加大收集数据的间隔，从而减少收集频率，就能控制生成的数据文件的规模，从而规避没法生成结果文件的问题。可是在实际操做时，因为测试时间、测试环境及操做等不少缘由，生成大文件有时没法避免，因此掌握处理大文件的方法仍是颇有必要的。

4 总结

以前在工做中遇到了几回.nmon文件较大的问题，当时没法处理这样的文件，致使性能测试报告中没法绘制CPU曲线。随着对.nmon文件的生成机制的了解，而且通过一段时间的摸索，总结出了本文的解决方案。虽然在生成的子文件较多时操做还有点繁琐，可是能够保证测试数据和CPU曲线的精确生成，避免因为大文件没法解析而致使的性能测试结果丢失的问题。

 

本文为原创，转载请注明出处，谢谢。