1、安装nmon
1.1 非arm架构的系统安装
软件下载地址
链接: https://pan.baidu.com/s/1xQJkBi9dUcrIcDwgsczC9g 提取码: xqdu
将nmon直接放入文件夹usr/bin下面(该目录下可以直接打nmon命令,无需进入nmon安装目录再执行./nmon)，然后授权文件为可执行文件，命令输入：chmod 777 nmon
1.2 arm架构的系统安装
软件下载及安装说明链接:
https://pan.baidu.com/s/1T-JWkh2PYmA8lYUkQJciGw 提取码: 98ws
1.3 nmon安装碰到的问题
问题：安装完nmon，执行nmon命令时报错：
[root@localhost bin]# nmon
nmon: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by nmon)
第一步：检查依赖包版本信息，未存在该版本
[root@localhost bin]# strings /lib64/libc.so.6 |grep GLIBC_
GLIBC_2.2.5
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
GLIBC_2.4
GLIBC_2.5
GLIBC_2.6
GLIBC_2.7
GLIBC_2.8
GLIBC_2.9
GLIBC_2.10
GLIBC_2.11
GLIBC_2.12
GLIBC_PRIVATE
第二步：下载软件进行升级
上传压缩包至目录/usr/bin/
http://ftp.gnu.org/gnu/glibc/glibc-2.14.tar.gz
http://ftp.gnu.org/gnu/glibc/glibc-ports-2.14.tar.gz
tar -xvf glibc-2.14.tar.gz
tar -xvf glibc-ports-2.14.tar.gz
mv glibc-ports-2.14 glibc-2.14/ports
mkdir glibc-2.14/build
cd glibc-2.14/build
../configure --prefix=/usr --disable-profile --enable-add-ons --with-headers=/usr/include --with-binutils=/usr/bin
make
make install
第三步：再执行nmon命令验证
2、使用nmon
监控命令（5分钟）：nmon -F /opt/nmon/login_200user5min_01.nmon -t -s 3 -c 100
或 nmon -f -t -s 3 -c 60 -m /root/nmon/
1.显示CPU可按C，同样，Memory—M，Network I/O----N， Disk I/O---D如下：
其中各参数表示：
-f 按标准格式输出文件：
-F 指定输出的文件名，比如test.nmon
-N include NFS sections
-m 切换到路径去保存日志文件
-s 每隔n秒抽样一次，这里为30
-c 取出多少个抽样数量，这里为60，即监控=120(30/60/60)=1小时
根据小时计算这个数字的公式为：c=h3600/s，比如要监控10小时，每隔30秒采样一次，则c=10*3600/30=1200
该命令启动后，会在nmon所在目录下生成监控文件，并持续写入资源数据，直至360个监控点收集完成——即监控1小时，这些操作均自动完成，无需手工干 预，测试人员可以继续完成其他操作。如果想停止该监控，需要通过“#ps –ef|grep nmon”查询进程号，然后杀掉该进程以停止监控。
3、使用nmon Analyser工具查看分析
打开nmon Analyser,点击excel中的按钮，选择nmon文件即可
nmon Analyser下载地址
链接: https://pan.baidu.com/s/1QlfWdrpyWJjq_a6--ltEAg 提取码: umrp
https://blog.csdn.net/zhouping19851013/article/details/82899003
4、nmon数据统计
内存使用率=(1-（memfree+cached+buffers）/memtotal)*100%
kill -9 pidof nmon
5、资源瓶颈分析
5.1 磁盘瓶颈分析
磁盘IO的主要指标有三个(IOPS、带宽、响应时间)
磁盘繁忙程度
Diskbusy体现了磁盘驱动的利用率，即磁盘驱动有百分之多少时间是活动的。
但这个指标的高低与IOPS、带宽并不是线性关系。例如当diskbusy=80%的时候IOPS=500，当diskbusy=90%的时候IOPS可能可以达到800。
可以把驱动理解为道路，每个IO的数据块理解为道路上行使的汽车。当道路上没有车的时候，认为是不活动的;当道路上有车的时候，认为是活动的，但有1辆车也是活动，有10辆车也是活动。因此diskbusy并不能作为磁盘IO的重要性能指标。但在日常情况下，可以从这个值的高低对磁盘使用情况有个大概的判断。
一般磁盘要和cpu wait对比的看，当diskbusy高且cpu wait也高说明磁盘已达瓶颈。CPU wait达30%~50% 属于瓶颈，磁盘繁忙比50%以上是瓶颈。
5.2 CPU瓶颈分析
CPU、内存资源最主要的指标只有一个，即利用率。
CPU超过70% 则会存在瓶颈。
一般来说在实际的应用中有一个70%的指导值，也就是说在IO读写的队列中，当队列大小小于最大IOPS的70%的时候，IO的响应时间增加会很小，相对来说让人比较能接受的，一旦超过70%，响应时间就会戏剧性的暴增，所以当一个系统的IO压力超出最大可承受压力的70%的时候就是必须要考虑调整或升级了。
一般情况下CPU利用率里User%应占70%左右，Sys%应占30%左右，如果Sys%或Wait%占比等于或超过了User%则应该关注是什么引起了过多的系统消耗，可能是大量的Disk或Network I/O。
CPU：
Users%：显示采集间隔内所有CPU在User Mode下的Time占比（Avg、Max）。
Sys%：显示采集间隔内所有CPU在System Mode下的Time占比（Avg、Max）。
Wait%：显示采集间隔内所有CPU处于空闲且等待I/O完成的时间比例（Wait%是CPU空闲状态的一种，当CPU处于空闲状态而又有进程处于D状态（不可中断睡眠）时，系统会统计这时的时间，并计算到Wait%里），Wait%不是一个时间值，而是时间的比例，因此在同样I/O Wait时间下，服务器CPU越多，Wait%越低，它体现了I/O操作与计算操作之间的比例。对I/O密集型的应用来说一般Wait%较高，且Sheet PROC中Blocked也较高，这时需关注是什么导致了过多的进程等待。
Idle%：显示采集间隔内所有CPU处于空闲Time的占比（Avg、Max）。
CPU%：显示采集间隔内所有CPU的user%+system%。