【原创】使用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曲线的精确生成，避免由于大文件无法解析而导致的性能测试结果丢失的问题。

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