1. 为什么我至今还在用nmon做性能监控第一次接触nmon是在一台跑了三年多的老业务服务器上当时业务方反馈每天下午三点左右系统会卡顿几分钟但登录上去用top看CPU和内存都挺正常用iostat看磁盘也看不出明显异常。问题排查了两天没进展后来一位前辈丢给我一个二进制文件说“你把这个跑起来按几个键等出问题的时候再看”。那个文件就是nmon。它把CPU、内存、磁盘、网络、文件系统这些指标全部按时间轴记录下来事后回放的时候一眼就看出是下午三点有个定时任务把磁盘IO打满了而top恰好没抓到那个瞬间。从那以后nmon就成了我排查Linux性能问题的常备工具。它跟top、vmstat、iostat这些命令最大的区别在于nmon是“录制回放”模式而不是“实时看一眼”。实时工具的问题是你盯着屏幕的时候问题往往不出现等你走开了问题来了你什么也没留下。nmon把数据按固定间隔写进文件事后可以慢慢分析这对定位间歇性性能问题特别有用。这篇文章面向的是需要在Linux服务器上做性能监控和问题排查的运维、开发、DBA以及任何需要搞清楚“服务器到底在干什么”的人。不管你之前有没有用过nmon我都会从安装讲到实际使用把参数选择、数据解读、踩过的坑都讲清楚。nmon本身不复杂但要用好它得知道在什么场景下看哪些指标以及那些数字背后到底意味着什么。2. nmon到底是什么跟其他监控工具比优势在哪2.1 nmon的核心定位一个二进制文件搞定所有指标nmon的全称是Nigels Monitor最早由Nigel Griffiths在IBM工作时开发用来监控AIX系统的性能。后来移植到Linux平台现在在主流Linux发行版上都能跑。它的本质是一个单文件的可执行程序不依赖复杂的运行时环境不需要装一堆依赖库下载下来给个执行权限就能用。这个特性在实际工作中非常关键。你想想生产服务器出问题的时候你往往没有权限装软件或者不想因为装监控工具引入新的依赖风险。nmon就一个文件scp上去chmod x直接跑对系统几乎零侵入。我遇到过客户环境连包管理器都被锁了的情况nmon照样能用。它采集的指标覆盖了日常排查需要的绝大部分维度CPU用户态、系统态、等待IO、空闲的比例以及每个核心的负载内存物理内存使用、虚拟内存、swap使用、页交换速率磁盘每个磁盘的读写速率、IOPS、平均等待时间、繁忙程度网络每个网卡的收发速率、包量、错误和丢包文件系统各挂载点的空间使用率、inode使用率进程CPU占用最高的进程、内存占用最高的进程内核上下文切换、中断、fork速率等这些指标在nmon里是按时间序列记录的你可以设置每10秒、30秒、60秒采集一次跑几个小时甚至几天最后生成一个数据文件用nmon的分析器或者Excel插件来可视化。2.2 跟top、vmstat、sar的对比什么时候该用nmon很多人会问系统自带的top、vmstat、sar不也能看这些指标吗为什么还要用nmon这个问题问得好我来说说我的理解。top和vmstat是实时快照工具你运行的时候看到的是当前瞬间的状态。它们的优势是即时反馈适合你正在操作服务器、想快速看一眼负载情况。但它们的劣势也很明显数据不留存你没法回看。而且top默认的刷新间隔是3秒有些瞬时峰值可能被平滑掉。sar是历史记录工具它依赖sysstat服务在后台定期采集数据可以回看过去某段时间的指标。sar的优势是数据自动采集不需要你手动启动。但它的采集粒度受限于sysstat的配置默认10分钟一次对于排查分钟级的性能抖动来说太粗了。而且sar的配置和日志轮转有时候会出问题我就遇到过sysstat服务挂了导致历史数据断档的情况。nmon的定位介于两者之间手动启动、按需采集、粒度可控、数据可回放。你可以在怀疑有问题的时候启动nmon设置10秒或30秒的采集间隔跑一两个小时然后拿数据文件分析。它不依赖后台服务不会因为服务挂掉而丢数据采集粒度也足够细。下面这个表格可以帮你快速判断什么场景该用什么工具工具数据留存采集粒度依赖服务适用场景top无实时无快速查看当前负载vmstat无实时无查看CPU、内存、IO整体趋势sar有默认10分钟sysstat回看历史趋势粗粒度nmon有可设10秒起无排查间歇性性能问题细粒度回放2.3 nmon的两种运行模式交互式和录制式nmon有两种用法很多人只知道第一种。交互式模式直接运行nmon会进入一个全屏的字符界面你按不同的键切换不同的指标视图。比如按c看CPU按m看内存按d看磁盘按n看网络。这个模式适合你坐在服务器前实时观察跟top的体验类似但信息密度更高一个屏幕能看更多指标。录制式模式运行nmon -f -s 10 -c 360这样的命令nmon会在后台按每10秒一次、共采集360次也就是1小时的频率把数据写到一个.nmon文件里。这个模式适合无人值守的长时间采集采集完成后你用分析工具打开文件回放整个时间段的所有指标。实际工作中录制式模式才是nmon的核心价值所在。交互式模式虽然直观但你能盯着屏幕的时间有限而录制式可以让你在问题发生后从容分析。我个人的习惯是日常巡检用交互式快速扫一眼怀疑有问题或者要做性能基线的时候用录制式跑一段时间。3. 安装nmon不同发行版的实操方法3.1 先确认你的系统环境和架构安装之前先搞清楚两件事发行版类型和CPU架构。nmon是编译好的二进制文件不同发行版和架构的二进制不通用。查看发行版信息cat /etc/os-release查看CPU架构uname -m常见的架构有x86_64也就是64位Intel/AMD、aarch64ARM 64位比如鲲鹏、飞腾服务器、ppc64leIBM Power。你得根据架构选对应的nmon二进制。3.2 包管理器安装最省事的方式如果你用的是主流发行版优先试试包管理器这是最省事的方式。Debian/Ubuntu系列sudo apt update sudo apt install nmonRHEL/CentOS系列sudo yum install nmonFedorasudo dnf install nmonopenSUSEsudo zypper install nmon包管理器安装的好处是自动处理依赖和路径装完直接就能用。但有个问题不是所有发行版的仓库里都有nmon。比如某些精简版的CentOS最小化安装仓库里可能没有nmon包。这时候就得用下面的手动安装方式。注意有些发行版的仓库里nmon版本比较老可能不支持某些新特性。如果你需要最新版本建议手动下载。3.3 手动下载二进制包管理器找不到时的方案nmon的官方发布地址在IBM的社区页面上但那个页面有时候访问不稳定。更可靠的方式是从你所用发行版的官方源或者可信的镜像站下载对应的二进制包。以CentOS/RHEL为例如果你知道系统版本可以直接下载对应的rpm包# 查看系统版本 cat /etc/redhat-release # 下载对应版本的nmon rpm包以CentOS 7为例 wget https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/n/nmon-16g-3.el7.x86_64.rpm # 安装 sudo rpm -ivh nmon-16g-3.el7.x86_64.rpm如果是Debian/Ubuntu可以下载deb包wget http://archive.ubuntu.com/ubuntu/pool/universe/n/nmon/nmon_16g-3_amd64.deb sudo dpkg -i nmon_16g-3_amd64.deb手动下载的时候要注意版本匹配。比如CentOS 7的包不能装在CentOS 8上amd64的包不能装在ARM机器上。下错了装不上还是小事万一装上了不兼容的版本跑起来出各种奇怪错误更麻烦。3.4 源码编译需要定制或者最新版时用如果你需要最新版本或者你的架构比较特殊没有现成的二进制那就得从源码编译。nmon的源码是C语言写的编译很简单。# 下载源码 wget https://sourceforge.net/projects/nmon/files/nmon16m_source.tar.gz # 解压 tar -xzf nmon16m_source.tar.gz cd nmon16m_source # 根据你的架构选择编译目标 # 对于64位x86 make nmon_x86_64 # 对于ARM 64位 make nmon_arm64 # 编译完成后会生成对应的可执行文件 ls -la nmon*编译出来的文件可以直接用也可以复制到/usr/local/bin/下方便调用sudo cp nmon_x86_64 /usr/local/bin/nmon sudo chmod x /usr/local/bin/nmon源码编译的好处是你可以针对自己的环境做优化也能拿到最新版本。缺点是得装编译工具链gcc、make这些如果服务器上没装还得先装这些。3.5 安装后的验证确认nmon能正常工作装完之后别急着用先验证一下# 查看版本 nmon -V # 或者直接运行看帮助 nmon -h如果能看到版本信息和帮助输出说明安装成功了。如果提示command not found检查一下nmon的路径是不是在PATH里或者用绝对路径运行。实操心得我习惯把nmon放到/usr/local/bin/下这个路径默认在PATH里所有用户都能直接调用。如果放到/opt/或者其他目录记得要么加软链接要么用绝对路径。4. nmon录制模式的核心参数与实操4.1 录制命令的参数拆解nmon录制模式的基本命令格式是这样的nmon -f -s 间隔秒数 -c 采集次数 -m 输出目录 -T -t每个参数的含义-f必须加表示以录制模式运行输出到文件。不加这个参数就是交互式模式。-s采样间隔单位秒。默认是10秒可以设成5秒、30秒、60秒等。-c采集次数。总采集时长 间隔 × 次数。比如-s 10 -c 360就是采集1小时。-m输出目录。不加的话默认输出到当前目录。-T在输出文件里记录命令行参数方便以后知道当时是怎么采集的。-t把CPU占用最高的进程也记录下来。这个参数很实用排查问题的时候能直接看到是哪个进程在吃CPU。一个典型的录制命令nmon -f -s 10 -c 360 -m /tmp/nmon_data -T -t这条命令的意思是每10秒采集一次共采集360次1小时输出到/tmp/nmon_data目录记录命令行参数同时记录TOP进程。4.2 采集间隔和时长怎么定这是最常被问到的问题间隔设多少合适采集多久我的经验是根据问题的特征来定。如果你要排查的是秒级的性能抖动间隔设5秒甚至更短如果是看整体趋势30秒或60秒就够了。间隔越短数据文件越大但精度越高。数据文件的大小可以估算大约每个采集点产生1KB到2KB的数据。比如-s 10 -c 360360个采集点文件大概360KB到720KB。这个大小完全可以接受。如果你跑一整天-s 60 -c 1440文件也就1.5MB到3MB。采集时长方面我一般建议至少覆盖一个完整的业务周期。比如你要排查下午三点的卡顿那就从两点半开始采集跑到四点覆盖问题发生前后的时间段。如果问题不规律那就跑长一点比如24小时看看有没有周期性规律。注意nmon本身对系统资源的消耗很小CPU占用通常不到1%内存占用也就几MB。但如果你把间隔设成1秒采集点非常多写文件的IO可能会有轻微影响。生产环境建议间隔不要低于5秒。4.3 后台运行与停止采集nmon录制模式默认就是后台运行的命令执行后会立刻返回nmon在后台默默采集。你可以用ps确认一下ps -ef | grep nmon如果要提前停止采集直接kill掉进程就行# 找到nmon进程的PID ps -ef | grep nmon | grep -v grep # kill掉 kill PIDnmon收到kill信号后会正常关闭文件数据不会丢。采集完成后输出目录里会出现一个以主机名和日期时间命名的.nmon文件比如server01_240115_1430.nmon。4.4 输出文件命名规则与批量管理nmon的输出文件命名格式是主机名_日期_时间.nmon。这个命名规则在多台服务器同时采集的时候很有用你一眼就能看出是哪个机器、哪个时间段的数据。如果你要同时监控多台服务器可以写个简单的脚本批量启动#!/bin/bash # 在多台服务器上启动nmon采集 SERVERSserver01 server02 server03 for srv in $SERVERS; do ssh $srv nmon -f -s 10 -c 360 -m /tmp/nmon_data -T -t echo $srv nmon started done采集完成后把各台机器的.nmon文件收集到一起分析。我习惯按日期建目录比如/data/nmon/2024-01-15/把当天的所有文件放进去方便归档和查找。5. 数据文件的分析与可视化5.1 用nmon分析器打开数据文件采集到的.nmon文件是文本格式的你可以直接用cat或less看但那样看效率太低。nmon官方提供了一个分析器可以把数据文件转成CSV格式然后用Excel或者其它工具做图表。分析器有几种形式nmon analyser一个Excel宏文件打开后导入.nmon文件自动生成各种图表。这是最常用的方式适合在Windows或Mac上用。nmonchart一个shell脚本把.nmon文件转成HTML格式的图表适合在Linux上直接用浏览器看。nmon2csv把.nmon文件转成CSV然后你自己用Python或其它工具处理。我平时用得最多的是nmon analyser因为图表直观而且可以自定义要看哪些指标。nmonchart适合快速查看不需要装Excel。5.2 关键指标解读CPU、内存、磁盘、网络拿到数据后怎么看出问题我来说说几个关键指标的解读方法。CPU指标重点看User%、Sys%、Wait%、Idle%这四个。如果User%高说明应用在消耗CPU如果Sys%高说明内核在忙可能是系统调用多或者IO操作频繁如果Wait%高说明CPU在等IO瓶颈在磁盘或网络如果Idle%很低但User%和Sys%都不高那可能是Wait%吃掉了CPU时间。内存指标重点看memfree、memcache、swpused、pgscan。memfree低不一定是问题因为Linux会用空闲内存做缓存memcache。真正要关注的是swpused如果swap使用率持续增长说明物理内存不够了。pgscan是页扫描速率如果这个值很高说明系统在频繁回收内存页内存压力大。磁盘指标重点看每个磁盘的Busy%、Read/s、Write/s、Avg Wait。Busy%接近100%说明磁盘是瓶颈。Avg Wait是平均IO等待时间单位毫秒如果这个值超过20ms说明磁盘响应慢。注意要看具体是哪个磁盘不要只看汇总。网络指标重点看每个网卡的Read/s、Write/s、Packets/s、Errors。如果Errors或Dropped不为零说明网络有问题可能是网卡、交换机或者线缆的问题。5.3 用nmonchart生成HTML报告如果你不想装Excel或者需要在Linux服务器上直接看nmonchart是个好选择。它是一个shell脚本依赖gnuplot和awk。# 安装依赖 sudo apt install gnuplot # Debian/Ubuntu sudo yum install gnuplot # RHEL/CentOS # 下载nmonchart wget https://sourceforge.net/projects/nmon/files/nmonchart40.tar tar -xf nmonchart40.tar # 转换数据文件 ./nmonchart server01_240115_1430.nmon server01_240115_1430.html生成的HTML文件用浏览器打开里面是各种交互式图表可以缩放、悬停查看具体数值。这个方式特别适合在服务器上直接分析不需要把文件传到本地。5.4 把数据导入Excel做自定义分析nmon analyser生成的图表虽然全但有时候你只想看某几个指标或者想做自定义的计算。这时候可以把.nmon文件转成CSV然后导入Excel自己处理。用nmon2csv转换# 下载nmon2csv wget https://sourceforge.net/projects/nmon/files/nmon2csv.tar tar -xf nmon2csv.tar # 转换 ./nmon2csv.pl server01_240115_1430.nmon转换后会生成多个CSV文件每个文件对应一类指标CPU、内存、磁盘等。你可以用Excel打开做透视表、画趋势图或者用Python的pandas做更复杂的分析。实操心得我经常把nmon数据转成CSV后用Python做自动化分析比如计算某段时间内的CPU峰值、磁盘IO平均值、网络流量趋势等。这样比手动看图表效率高得多而且可以做成定期报告。6. 常见问题与排查技巧实录6.1 nmon启动报错权限不足或文件已存在问题现象运行nmon命令后提示Permission denied或者File exists。排查思路Permission denied通常是输出目录没有写权限。检查-m指定的目录是否存在、当前用户是否有写权限。File exists是nmon默认不会覆盖已存在的输出文件。如果你在同一分钟内多次启动文件名会冲突。解决办法是等一分钟再启动或者手动指定不同的输出目录。解决方法# 确保输出目录存在且有写权限 mkdir -p /tmp/nmon_data chmod 755 /tmp/nmon_data # 如果文件名冲突换个目录或者等一分钟6.2 采集到的数据文件为空或很小问题现象采集完成后.nmon文件只有几KB或者打开后没有数据。排查思路检查nmon进程是否真的在运行。有时候命令执行后立刻退出了可能是参数写错了。检查采集次数和间隔。如果-c设得很小比如-c 1那就只采集一次数据自然少。检查磁盘空间。如果输出目录所在分区满了nmon写不进去数据。解决方法# 确认nmon进程在运行 ps -ef | grep nmon # 检查磁盘空间 df -h /tmp/nmon_data # 重新运行确保参数正确 nmon -f -s 10 -c 360 -m /tmp/nmon_data -T -t6.3 分析器打开文件报错格式不兼容问题现象用nmon analyser打开.nmon文件时提示格式错误或者图表显示不全。排查思路检查nmon版本和分析器版本是否匹配。老版本的分析器可能不支持新版本nmon生成的文件格式。检查文件是否完整。如果采集过程中nmon被强制kill文件可能不完整。检查文件编码。有些环境下nmon输出的文件编码可能不是UTF-8导致分析器读取出错。解决方法升级nmon和分析器到最新版本。确保采集完成后正常停止nmon不要强制kill -9。如果编码有问题可以用iconv转换iconv -f ISO-8859-1 -t UTF-8 server01_240115_1430.nmon server01_utf8.nmon6.4 采集间隔太短导致系统负载升高问题现象设置了很短的采集间隔比如1秒发现系统负载反而升高了。排查思路nmon本身消耗不大但采集间隔太短会导致频繁写文件如果输出目录在慢速磁盘上IO等待会增加。另外nmon采集进程信息时会遍历/proc间隔太短也会增加CPU开销。解决方法生产环境采集间隔不要低于5秒推荐10秒或30秒。把输出目录设在内存文件系统上比如/dev/shm减少磁盘IOnmon -f -s 5 -c 720 -m /dev/shm -T -t采集完成后记得把文件从/dev/shm移走否则重启会丢。6.5 常见问题速查表问题现象可能原因解决方法启动报Permission denied输出目录无写权限检查目录权限chmod 755启动报File exists文件名冲突换目录或等一分钟数据文件为空nmon未正常运行或参数错误检查进程和参数分析器报格式错误版本不匹配或文件不完整升级版本正常停止nmon系统负载升高采集间隔太短间隔调到5秒以上数据文件太大采集时间太长或间隔太短调整参数定期归档避坑技巧我习惯在启动nmon之前先跑一次nmon -h确认版本和参数支持情况。有些老版本的nmon不支持-T或-t参数加了会报错。另外采集完成后一定要确认nmon进程已经退出有时候kill信号没生效进程还在后台跑会一直写数据占空间。7. 把nmon用成日常巡检和性能基线的工具nmon最被低估的用法是做性能基线。什么叫性能基线就是在系统正常的时候用nmon采集一段时间的指标存下来作为“正常状态”的参考。以后系统出问题的时候拿当前数据和基线对比就能快速判断是哪个指标偏离了正常范围。我一般会在业务低峰期比如凌晨采集2到4小时的nmon数据作为基线。采集命令nmon -f -s 30 -c 480 -m /data/nmon/baseline -T -t这条命令每30秒采集一次共采集480次4小时。采集完成后把文件归档标注好日期和系统状态。以后排查问题的时候把问题时段的数据和基线数据放在一起对比。比如基线里CPU的User%平均是20%问题时段变成了80%那明显是应用层的问题。如果基线里磁盘Avg Wait是5ms问题时段变成了50ms那瓶颈在磁盘。这个做法看起来简单但实际效果非常好。很多性能问题不是“绝对值高”而是“相对正常状态偏离大”。有了基线你就有了一把尺子。另外nmon也可以配合定时任务做定期巡检。比如每天凌晨自动采集1小时存到指定目录保留最近30天。这样万一出了问题你至少有历史数据可以回看。# 添加到crontab 0 2 * * * /usr/local/bin/nmon -f -s 60 -c 60 -m /data/nmon/daily -T -t这条cron表示每天凌晨2点启动nmon每60秒采集一次共60次1小时输出到/data/nmon/daily目录。配合一个清理脚本定期删除30天前的文件就能实现自动化的性能巡检。我个人在实际操作中的体会是nmon的价值不在于它有多复杂而在于它足够简单、足够可靠。一个二进制文件几条参数就能把服务器的性能状态完整记录下来。真正花时间的是分析数据、理解指标背后的含义以及把数据跟业务表现关联起来。工具只是手段搞清楚“服务器到底在干什么”才是目的。