1. Nmon使用
1.1 下载软件
1) 下载之前须确定操作系统内核版本，本文以公司服务器192.168.40.212为例。登录服务器使用命令获取操作系统版本信息：
查看可知为Enterprise Linux Server release 5.5。
2) 登录IBM官方网站（http://nmon.sourceforge.net/pmwiki.php?n=Site.Download）下载相应版本的nmon工具：nmon_linux_14g.tar.gz
1.2 安装软件
1) 用root用户登录系统，建立目录：#mkdir /nmon
2) 通过FTP将下载的nmon工具上传至服务器 192.168.40.212目录/nmon下。
3) 修改tar包权限：#chmod +x nmon_linux_14g.tar.gz
4) 解压文件：#tar xvfZ nmon_linux_14g.tar.gz
5) 执行授权命令：#chmod +x nmon_x86_rhel54
1.3 运行界面
1) 运行./nmon_x86_rhel54，便可进入nmon的监控界面，如下图：
2) 键入“c”查看系统CPU使用情况
3) 键入“m”查看系统内存使用情况
4) 键入“d”查看系统磁盘I/O情况
5) 键入“h”查看帮助信息
1.4 使用方法
1.4.1 实时监控
在完成配置后，只需要“#./nmon”命令即可运行程序，通过一些快捷键调取关心的系统资源指标进行显示，如按键“C”可以查看CPU相 关信息；按键“D”可以查看磁盘信息；按键“T”可以查看系统的进程信息；“M”对应内存、“N”对应网络等等，完整的快捷键对应内容可以通过帮助（按键 “H”）查看，可以显示Linux系统CPU、内存、进程信息，包括了CPU的用户、系统、等待和空闲状态值，可用内存、缓存大小以及进程的CPU消耗等详细指标。
该种方式显示信息实时性强，能够及时掌握系统承受压力下的运行情况，每颗CPU利用率是多少、内存使用多少、网络流量多少、磁盘读写……这些数据均是实时刷新，一目了然。
1.4.2 后台监控
为了配合性能测试，我们往往需要将一个时间段内系统资源消耗情况记录下来，这时可以使用命令在远程窗口执行命令：
./nmon/ nmon_x86_rhel5 -f -N -m /nmon/log -s 30 -c 120
其中各参数表示：
-f 按标准格式输出文件：<hostname>_YYYYMMDD_HHMM.nmon
-N include NFS sections
-m 切换到路径去保存日志文件
-s 每隔n秒抽样一次，这里为30
-c 取出多少个抽样数量，这里为120，即监控=120*(30/60/60)=1小时
根据小时计算这个数字的公式为：c=h*3600/s，比如要监控10小时，每隔30秒采样一次，则c=10*3600/30=1200
该命令启动后，会在nmon所在目录下生成监控文件，并持续写入资源数据，直至360个监控点收集完成——即监控1小时，这些操作均自动完成，无需手工干 预，测试人员可以继续完成其他操作。如果想停止该监控，需要通过“#ps –ef|grep nmon”查询进程号，然后杀掉该进程以停止监控。
1.4.3 定时任务
除配合性能测试的短期监控，我们也可以实现对系统的定期监控，作为运营维护阶段的参考。定期监控实现如下：
1) 执行命令：#crontab –e
2) 在最后一行添加如下命令：
0 8 * * 1,2,3,4,5 /nmon/nmon_x86_rhel5 -f -N -m /nmon/log -s 30 -c 1200
表示：
周一到周五，从早上08点开始，监控10个小时（到18:00整为止），输出到/nmon/log
2. Nmon监控结果介绍
2.1 生成结果文件
通过后台监控和定期监控，我们可以得到扩展名为nmon的监控文件，这些文件记录着系统资源的数据，需要配合分析工具（nmon analyser）进行解读。
1) 使用FTP工具从服务器上取下生成结果文件/nmon/log/sjfx212_120318_1723.nmon到本机。
2) 打开nmon_analyser.zip 包下的nmon analyser v33g.xls 文件，点击Analyse nomn data按钮，选择之前get下来的sjfx212_120318_1723.nmon文件。
Excel可能禁止运行宏了，点“安全警告旁边的选项”，允许运行宏：
3) 生成分析结果文件sjfx212_120318_1723.nmon.xlsx，并生成统计图，直观显示系统资源情况。
2.2 主要性能参数介绍
u 系统汇总（对应excel标签的‘SYS_SUMM’）：其中蓝线为cpu占有率变化情况；粉线为磁盘IO的变化情况。
u 磁盘读写情况汇总（对应excel标签的‘DISK_SUMM’）： 其中蓝色为磁盘读的速率KB/sec；紫色为磁盘写的速率KB/sec。
u 内存情况汇总（对应excel标签的‘MEM’）： 曲线表示内存剩余量（MB）
2.3 页面介绍
简单介绍生成结果的各个页面：
1) 系统汇总页面：对应标签页（SYS_SUMM）
页面显示项主要有主机名,执行日期，系统cpu使用情况（蓝线），系统I/O情况（粉红线），其中坐标左纵轴为系统cpu（user%+sys%）使用率，横轴为运行时长（下图为一个小时），右纵轴为系统磁盘传输（Disk xfers），坐标下侧为统计信息：系统I/O情况（一个周期内的平均值、最大值、出现最大值的时间），系统CPU使用情况。
| 选项 |
说明 |
备注 |
| User% |
用户进程时间在CPU 开销时间百分比 |
如果一个CPU 被充分使用,利用率分类之间均衡的比例应该是： 65% - 70% User Time 30% - 35% System Time 0% - 5% Idle Time |
| Wait% |
所有进程线程被阻塞等待完成一次IO 请求所占CPU 开销idle的时间百分比 |
|
| Sys% |
线程和中断在CPU 开销时间百分比 |
|
| Idle% |
CPU 空闲时间的百分比 |
|
| CPU% |
CPU 利用率的百分比 |
注释：
如果系统CPU有IO wait存在，说明可能IO或内存方面存在瓶颈，其中主要导致IO Wait的主要原因如下：
ü 内存不够而引起频繁的的数据交换，导致数据存取存在交换空间的 I/O瓶颈
ü 硬盘数据分布不合理
2) 系统信息：标签页（AAA）
页面信息主要包括：执行命令，主机CPU数（4），操作系统内核版本信息，主机名等信息。
3) 系统详细信息：标签页（BBBP）
页面信息主要包括：操作系统版本，主机磁盘信息，主机CPU型号、主频信息，内存信息，网卡信息等。
4) CPU使用情况：标签页（CPU_ALL，CPU_SUMM，CPU001，CPU002，CPU003，CPU004）
主机CPU使用情况汇总以及单颗CPU的运行情况。
5) 磁盘读写情况汇总：标签页（DISK_SUMM，DISKBSIZE，DISKBUSY，DISKREAD，DISKWRITE，DISKXFER）
磁盘的读、写及I/O统计信息，系统各磁盘分区的读写情况。其中DISKBUSY页主要反映系统本地磁盘使用，DISK_SUMM包括本地和存储（ESS, EMC, FASt及HDS）上所有磁盘使用情况。
6) 内存使用情况：标签页（MEM）
系统内存空闲、使用，swap、cached等统计信息。
7) 系统网络情况：标签页（NET，NETPACKET）
反映系统的网络运行情况，系统各个网络适配器读写的数据包数
8) 系统进程：标签页（PROC）
反映系统运行线程及等待切换的线程平均数。其中RunQueue - 每个处理器应该运行队列不超过1-3个线程。
9) 活动虚拟内存总量：标签页（VM）
Linux操作系统特有指标，主要包括系统/proc/vmstat文件中信息，两张图片主要显示系统分页文件（pagefile）和swap分区运行情况。如果系统总是存在大量换出页（pgpgout/s）KB数,说明系统需要更多内存。
10) 页式调度：标签页（PAGE）
记录系统（AIX）页式调度的情况。这一栏主要记录系统换页（paging）情况和页面扫描：自由比率（page scan:free ratio）。其中系统换页频率应该不大于5次/秒，而当页面扫描：自由比率持续大于4时，需要重点关注下系统内存和分页空间的使用情况。
说明：
大量的内存交换操作会极大地影响系统的性能，尤其是在当数据库文件创建在文件系统上时(JFS and JFS2)。在这种情况下经常访问的数据，即在SGA中存在，也同样在文件的缓存中存在。这种相同的数据在内存中缓存两次的情况，会降低内存的使用效率，从而使内存频繁进行交换操作，造成系统的I/O瓶颈，降低整个系统的性能。
11) 采集时间：标签页（ZZZZ）
记录nmon工具采集系统信息的时间点。
3. Nmon监控案例介绍
本节介绍通过nmon工具发现系统性能下降问题的常见现象和处理流程。
3.1 常见现象和产生原因
性能下降（Performance Degradation），主要是指系统的性能随时间而逐渐下降（这里假定在系统性能下降的过程中系统的负载状况没有明显变化）。系统运行过程中占用的CPU或内存随时间增加也属于广义的性能下降问题。
在生产环境中，通常由终端客户最先感觉到并报告性能下降问题。所以狭义的性能下降问题主要是指系统运行指标随时间变化，比如吞吐率随时间下降或页面响应时间随时间上升，或者两者兼而有之。
下面列举一些引起性能下降问题的原因：
ü 应用程序资源使用问题。主要是内存使用问题，即由于应用服务器的内存碎片问题或内存泄漏问题，导致垃圾回收的开销随时间增大。也有可能是因为磁盘临时文件积累造成磁盘访问开销增大。
ü 应用程序设计问题。由于应用程序的设计存在可扩展性或可靠性问题，导致运行开销随时间或业务对象的积累而增大。
ü 数据库访问问题。该问题又可以分为许多类型，如调优参数问题、表结构或索引设计问题、垃圾数据问题等。其共同特点是导致应用程序利用特定操作访问数据库的开销随时间而增大。
ü 服务器软件资源使用问题。虽然可能性很小，但是应用服务器、数据库服务器等服务器程序也是软件程序，也有可能存在性能下降问题。这些服务器程序在自身测试过程中可能遗漏了某些性能问题，而在用户特定的执行状况下触发了这些问题，结果导致这些服务器程序使用的操作系统资源泄漏而出现性能下降问题。
ü 测试用例设计问题。性能测试中有可能发现一些“假”的性能下降问题。比如测试用例设计时假设在测试执行过程中系统负载保持恒定，但实际的测试用例实现导致系统负载或特定页面的处理内容随时间增多，也可能导致测试工具的测试报告中出现性能下降问题。
3.2 实例介绍
3.2.1 示例一
图5-1 nmon操作系统监视汇总信息图
由此信息图可发现在12小时测试进行过程中，系统的磁盘传输（Disk xfers）逐渐增大，与此同时系统CPU占用率逐渐下降。进一步检查单个CPU的使用情况，发现1号CPU的Wait状态占用率明显增大，如图5-2所示。这说明CPU占用率逐渐下降是由于等待磁盘I/O引起的。
图5-2 nmon单个CPU使用情况图
接下来分析磁盘传输汇总信息，如图5-3所示，可以看出磁盘写数据量没有明显增加，但是磁盘读数据量明显随时间而增加。
图5-3 nmon磁盘传输汇总情况图
凭磁盘传输汇总信息，在排除由应用服务器读取导致的性能下降问题后，基本可以肯定不断增加的磁盘读取操作是由数据库引起的。
随后，分析DB2的快照监视器的监视结果，可以发现DB2的缓冲池（Buffer pool）的数据和索引物理读（physical read）的比例非常高。如下例所示：
Buffer pool data logical reads = 5502388
Buffer pool data physical reads = 430671
Buffer pool temporary data logical reads = 0
Buffer pool temporary data physical reads = 0
……
可以看到缓冲池的物理读比例（即缓冲池不命中率）高达7%，这远远大于1%的警戒线。而且物理读比例有随时间增加的趋势（通过不同时间的快照信息对比发现）。
至此可以怀疑性能下降问题是由于DB2的缓冲池配置参数设置不当引起的。考察数据库配置参数信息发现，该数据库的BUFFPAGE参数值为10000。与该测试用例使用的数据规模相比，这个参数值明显偏小。于是将BUFFPAGE参数值增大10倍，变为100000，重新运行性能测试，发现性能下降问题基本消失。
3.2.2 示例二
本实例为通过nmon监控河北税源管理平台数据仓库收集的数据。对照nmonanalyser工具生成结果进行分析。
1) 收集服务器基本信息
通过以上数据可以知道河北数据仓库服务器基本配置信息如下：
ü 主机名：HE_SSGLY_DB_01
ü 操作系统版本：AIX 5.3.0.44 build 5300-04
ü 操作系统内核：HW-type=CHRP=Common H/W Reference Platform Bus=PCI LPAR=Dynamic Multi-Processor 64 bit
ü 主机型号：IBM p5 595 (9119-595)
ü 网络配置：IP Address: 75.16.16.191 Sub Netmask: 255.255.248.0 Gateway: 75.16.16.100
ü 主机存储：EMC存储
ü 主机物理内存：49152 MB
ü 网卡信息：2块网卡 速率为1024M/S
2) 文件系统使用情况
通过以上数据可以知道河北数据仓库服务器文件系统相关信息如下：
ü 文件系统分区大小及使用情况
ü 文件系统挂载点信息
ü 文件系统类型为JFS2(Journaled File System 2)文件系统
3) 系统资源使用情况
观察上图，可以发现服务器cpu使用率较高的时段为8:00-11:30、14:00-17:20，而系统I/O开销较高的时段均出现在21:00-次日5:50。以上信息基本符合服务器晚上进行数据ETL处理、白天工作时段多进行平台一般事务处理的情况。进一步观察服务器cpu使用情况：
发现CPU利用率较高均为用户进程，单独查看CPU-11注意到22:00-0:00这个时段内CPU的Wait状态占用率明显增大， user状态占用率却很低，此时系统I/O明显升高，说明这个时段内有大量磁盘I/O发生，CPU占用率逐渐下降是由于等待磁盘I/O引起的。实际情况中，这个时段服务器正在进行ETL数据处理，的确有大量数据传输和磁盘读写发生。
3.2.3 示例三
介绍个利用nmon进行系统实时监控的例子。
把nmon脚本上传到服务中，直接运行即可，执行命令如下：#./nmon或者#/tmp/nmon/nmon
以下是aix5.3下使用nmon的一些截图：
分别输入c、t、n、m，可以了解系统cpu，内存，消耗资源最高的线程的使用情况。