nmon结果分析工具_使用nmon analyzer 分析指标

监控结果分析
使用nmon analyser对nmon文件进行解析，生成带图表信息的xlsx格式文件。

下载地址：http://nmon.sourceforge.net/pmwiki.php?n=Site.Nmon-Analyser

nmon analyser转换数据
进入工具目录，双击nmon analyser vxx_x.xlsm格式文件，进入工具界面。
如果界面提示安全警告，“宏已被禁用”，点击【启用内容】即可。
点击Analyze nmon data，选择待分析的nmon文件，等待分析、处理完成后，会在nmon文件目录下生成同名但后缀名为.xlsx的文件，后续分析在该xlsx文件中进行即可。

分析结果文件
在性能测试开始后启动nmon监控，通过设置监测时长使nmon在性能测试结束前退出，可以减少无关数据的收集。

打开nmon analyser转换的.xlsx的结果文件，每个指标对应结果文件中的同名sheet页，每个页面除了采样数据，还提供了对应的图表数据。.

一般在性能测试中，关键指标标红：

1、系统信息（AAA）

页面信息主要包括：执行命令，主机CPU数（4），操作系统内核版本信息，主机名等信息。

2、系统详细信息（BBBP）

页面信息主要包括：操作系统版本，主机磁盘信息，主机CPU型号、主频信息，内存信息，网卡信息等

3、CPU使用情况（CPU_ALL，CPU_SUMM，CPU001，CPU002，CPU003，CPU004…）

主机CPU使用情况汇总以及单颗CPU的运行情况

• SYS_SUMM：系统汇总页面，主要显示系统CPU（蓝线）和I/O（粉红线）的使用情况，其中坐标左纵轴为cpu（user%+sys%）使用率，横轴为运行时长，右纵轴为磁盘传输次数（Disk xfers），坐标图下方展示统计数据。

注意：

1）如果一个CPU被充分使用，利用率之间均衡的比例应该是：

User%: 65% ~ 70% , Sys%: 30% ~ 35% , Idle: 0% ~ 5%

2）CPU有IO wait存在，说明可能IO或内存方面存在瓶颈，其中主要导致IO Wait的主要原因如下： 内存不够而引起频繁的的数据交换，导致数据存取存在交换空间的 I/O瓶颈 硬盘数据分布不合理。

• CPU_ALL：CPU使用情况，展示在采样周期内服务器的CPU的使用情况，实际上，与SYS_SUMM展示的CPU数据是相同的，区别只是前者使用线状图表示。

• CPU_SUMM：CPU使用情况，页面展示的是每颗CPU的使用情况，与使用top命令，按数字键”1”显示各颗CPU的效果是一样的。

4、磁盘读写情况（DISK_SUMM，DISKBSIZE，DISKBUSY，DISKREAD，DISKWRITE，DISKXFER）

磁盘的读、写及I/O统计信息，系统各磁盘分区的读写情况。其中DISKBUSY页主要反映系统本地磁盘使用，DISK_SUMM包括本地和存储（ESS, EMC, FASt及HDS）上所有磁盘使用情况

• DISK_SUMM：主要显示磁盘读、写、IO情况，其中，需要注意的是：某一时间点的磁盘读写数据(Disk Read KB/s\Disk Write KB/s)等于该时间点上所有磁盘和分区的Read/Write的速率（KB/s）之和，分别与页面DISKREAD、DISKWRITE对应；某一采集时间点的IO/sec等于页面DISKXFER中该时间点上所有磁盘和分区的IO/sec之和。因此，该时间点上的I/O值统计是会有重复的。

• DISKBUSY：磁盘使用情况，主要显示各个磁盘及分区的繁忙程度，是磁盘使用时间和全部时间的比值，即磁盘有百分之多少时间是活动的。通常，根据该页面显示的磁盘百分比数据，可以快速了解该磁盘的使用情况。

5、内存使用情况（MEM）

系统内存空闲、使用，swap、cached等统计信息

6、系统网络情况：标签页（NET，NETPACKET）

反映系统的网络运行情况，系统各个网络适配器读写的数据

和网络有关工作表主要有如下几个：

• BBBN：网络的名字，速度和MTU大小
• BBBP：emstat和lsattr的结果，你可以看到netstat的信息
• NET：这一页显示了每张网卡的分时数据吞吐量，包括了读，写和总吞吐量（读+写）
• NETPACKET：这一页显示了每张网卡的分时传输的包数量，包括了读，写和总数
• NETSIZE：每张网卡上的包的大小

在进行分析之前，我们首先要确定网络的接口的一些参数，比如网卡类型，带宽和MTU。这些参数决定了网络接口的性能。如果你没有在Excel中找到网卡的类型和速度，可以通过以下命令查看。

首先，我们可以在linux上的/sys/class/net找到网络接口对应的网卡设备。

hugulas@hugulas-PC:/sys/devices$ ls -la /sys/class/net

total 0

drwxr-xr-x 2 root root 0 May 15 10:11 .

drwxr-xr-x 53 root root 0 May 15 10:11 ..

lrwxrwxrwx 1 root root 0 May 15 10:11 docker0 -> ../../devices
/virtual/net/docker0

lrwxrwxrwx 1 root root 0 May 24 16:02 enp1s0 -> ../../devices/
pci0000:00/0000:00:03.1/0000:01:00.0/net/enp1s0

lrwxrwxrwx 1 root root 0 May 24 16:02 lo -> ../../devices/virtual
/net/lo

然后，我们打开设备的speed文件看看网卡设备的速度：(我这张网卡是100Mbps的)

hugulas@hugulas-PC:/sys/devices$ cat /sys/class/net/enp1s0/speed

100

再次，还可以看看网卡的MTU：

hugulas@hugulas-PC:/sys/devices$ cat /sys/class/net/enp1s0/mtu

1500

如果我们想判断网卡是否瓶颈呢，我们可以先看excel中NET表来观察网络流量。这个页面有几张和网络流量有关的图表，也有分时分卡的网络流量数据。在按照网络接口来划分的直方图中我们可以看到流量集中在了千兆卡上，读和写的峰值分别是90MB/s和110MB/s，这张网卡是张千兆网卡1000Gbps（125MB/s），已经接近它的极限了。

从分时图也可以看到，瓶颈出现时，网络流量达到了一个瓶盖期。

我们接着再来看下网络的包大小。我没有拿到NETSIZE工作表，但是可以根据NETPACKETS算出包大小，峰值时，读写在210K/s，那么包大小大约在428到523Byte之间。包还是非常小的。如果包的大小比较小，那么这张卡的最大吞吐量会更差。（你的包的大小受制于MTU大小，最大不能大于MTU。所以，一般认为把MTU配成9000，对于高速网卡来说，性能会更好）。

结合以上两种数据，我们可以知道这张卡大概率到了瓶颈期。

7、系统进程（PROC）

反映系统运行线程及等待切换的线程平均数。其中RunQueue - 每个处理器应该运行队列不超过1-3个线程

8、页式调度：标签页（PAGE） 记录系统（AIX）页式调度的情况。

这一栏主要记录系统换页（paging）情况和页面扫描：自由比率（page scan:free ratio）。其中系统换页频率应该不大于5次/秒，而当页面扫描：自由比率持续大于4时，需要重点关注下系统内存和分页空间的使用情况 的内存交换操作会极大地影响系统的性能，尤其是在当数据库文件创建在文件系统上时(JFS and JFS2)。在这种情况下经常访问的数据，即在SGA中存在，也同样在文件的缓存中存在。这种相同的数据在内存中缓存两次的情况，会降低内存的使用效率，从而使内存频繁进行交换操作，造成系统的I/O瓶颈，降低整个系统的性能。

9、采集时间（ZZZZ）

记录nmon工具采集系统信息的时间点

Nmon监控常见现象和产生原因

性能下降（Performance Degradation），主要是指系统的性能随时间而逐渐下降（这里假定在系统性能下降的过程中系统的负载状况没有明显变化）。系统运行过程中占用的CPU或内存随时间增加也属于广义的性能下降问题。 在生产环境中，通常由终端客户最先感觉到并报告性能下降问题。所以狭义的性能下降问题主要是指系统运行指标随时间变化，比如吞吐率随时间下降或页面响应时间随时间上升，或者两者兼而有之。 下面列举一些引起性能下降问题的原因：

• 应用程序资源使用问题。主要是内存使用问题，即由于应用服务器的内存碎片问题或内存泄漏问题，导致垃圾回收的开销随时间增大。也有可能是因为磁盘临时文件积累造成磁盘访问开销增大。

• 应用程序设计问题。由于应用程序的设计存在可扩展性或可靠性问题，导致运行开销随时间或业务对象的积累而增大。

• 数据库访问问题。该问题又可以分为许多类型，如调优参数问题、表结构或索引设计问题、垃圾数据问题等。其共同特点是导致应用程序利用特定操作访问数据库的开销随时间而增大。

• 服务器软件资源使用问题。虽然可能性很小，但是应用服务器、数据库服务器等服务器程序也是软件程序，也有可能存在性能下降问题。这些服务器程序在自身测试过程中可能遗漏了某些性能问题，而在用户特定的执行状况下触发了这些问题，结果导致这些服务器程序使用的操作系统资源泄漏而出现性能下降问题。

• 测试用例设计问题。性能测试中有可能发现一些“假”的性能下降问题。比如测试用例设计时，假设在测试执行过程中系统负载保持恒定，但实际的测试用例实现导致系统负载或特定页面的处理内容随时间增多，也可能导致测试工具的测试报告中出现性能下降问题。