上周帮朋友处理一起Linux服务器凌晨卡顿的问题，最头疼的不是故障本身，而是等白天登录上去一切指标都恢复正常了——top里CPU空闲，free里内存充足，df也看不出半点异常。可业务确实在凌晨卡了将近半小时。没有当时的现场数据，性能问题就成了悬案。后来我在那台机器上装了nmon，让它每5秒记录一次系统状态，第二天把生成的.nmon文件丢进分析工具，十分钟不到就锁定了瓶颈。
nmon就是这样一个Linux综合监控工具：单个二进制文件、不需要安装依赖、既能交互式查看实时状态，也能后台定时采集数据，而且采集的数据可以离线生成图表。对运维和性能调优来说，它最大的价值不是“现在能看到什么”，而是“事后还能翻出证据”。这篇文章我从安装选型、交互操作、后台采数到数据分析和生产环境踩坑，按实操顺序展开，适合正在做服务器监控、性能排查，或者准备Linux相关面试的工程师参考。
1. 为什么我选了nmon而不是一堆单点命令
1.1 一条命令看清整机状态，省去来回切命令的麻烦
先说最直接的痛点。排查Linux性能问题，很多人习惯“三板斧”：top看CPU，free看内存，df看磁盘，要看网络就临时iftop或者sar。三板斧本身没错，问题是这些命令之间没有时间关联。你看到CPU高的时候，内存到底处于什么状态？网络流量是不是同时飙的？靠肉眼来回切换命令，看到的只是某一个瞬间的快照，而且在高负载场景下top刷屏速度极快，根本来不及细看。
nmon把CPU、内存、磁盘、网络、文件系统、进程、内核信息全部整合在一个字符界面里，通过按键切换维度，所有指标都在同一个屏幕刷新周期内呈现。这个“时间对齐”非常关键。比如top显示load average从2跳到12，但每个CPU核心都很闲，这时候基本可以怀疑是磁盘IO等待或者锁竞争。用nmon按d看磁盘busy率、按n看网络流量，状态栏里的数字会告诉你负载到底来自计算、IO还是网络。
实际排查时，我通常登录服务器后什么都不装，先起一个nmon，几秒钟就能扫完整机资源概况。不是说top没用，而是nmon把分散的信息集中到了一起，并且是以一种方便对比的方式展示的。遇到情况紧急的时候，省下的就是最宝贵的响应时间。
1.2 和top、sar、htop放在一起怎么选
很多人会问：我已经有top、htop、sar了，还有必要上nmon吗？我的看法是它们不是替代关系，而是互补关系。下面这个对比我用了很长时间，基本能代表我对这四类工具的理解。
| 工具 | 适合场景 | 短板 |
|---|---|---|
| top | 快速看实时CPU和进程排行 | 只有瞬态，不留历史，高负载时难观察 |
| htop | 交互体验好，彩色界面直观 | 同样不留历史，且依赖ncurses库 |
| sar | 可以定时记录历史指标 | 指标分散在不同文件中，同屏对比不方便 |
| nmon | 实时同屏监控 + 后台采集一条龙 | 更新节奏不如发行版仓库那么勤，需要自己关注版本 |
sar其实很强大，sysstat包里的采集能力很完整，但它的数据是分门别类的：CPU在cpu文件里，内存、网络各自独立。你想把同一时间点的CPU、内存、磁盘关联起来，需要自己拼数据。而nmon采集出的文件是统一格式，同一秒的CPU、内存、磁盘、网络记录在同一个文件的不同行里，分析的时候天然就能对齐。
所以我的习惯是：日常巡检和故障复盘用nmon做后台采集，实时应急排查用nmon交互界面，历史趋势类的长期监控交给专门的监控系统，sar作为补充。这样搭配下来，既不会漏现场，也不会重复造轮子。
2. 安装选型：单文件免安装的省心之处与最容易踩的架构坑
2.1 下载解压就能跑，生产服务器不需要装编译链
nmon最讨喜的一点是它本质上就是一个静态编译的二进制文件，不依赖一堆动态库，也不需要make install。它的Linux版可以从SourceForge上找到，解压之后里面是多个带不同平台后缀的二进制文件，挑对架构直接chmod +x就能运行。Debian/Ubuntu环境下也可以直接用apt install nmon装发行版仓库里的版本，但版本通常不是最新的；CentOS/RHEL如果没有配置EPEL源，直接下载官方二进制反而更省事。
我一般是这样部署的：
- 在SourceForge下载最新的nmon Linux压缩包，顺手做一下sha256校验；
- tar解压，找到对应CPU架构的二进制文件；
- 复制到/usr/local/bin目录，chmod 755赋予执行权限；
- 运行
nmon验证是否正常。
整个过程不需要编译工具链，这一点在干净的生产服务器上尤其重要。你为装一个监控工具引入gcc、make这些依赖，本身就扩大了风险面。单文件部署还有一个好处：想批量部署时，只需要把同一个二进制复制到几十台机器上，目录结构统一，脚本管理起来非常方便。
2.2 x86_64和aarch64（很多人搜成arrch64）别搞混
解压之后最需要留意的就是选对CPU架构。X86服务器用x86_64版本，ARM服务器或者部分嵌入式平台要用aarch64版本。我看到不少朋友在搜“nmon监控工具arrch64”，其实正确的拼法是aarch64，压缩包里对应的文件通常带aarch64字样。这里提一句：ARM版本在部分深度定制过的系统上使用时，要注意发行版对二进制的兼容性，最简单的判断方式是启动前先用file命令看一下架构。
file /usr/local/bin/nmon如果跑起来报“cannot execute binary file: Exec format error”，基本就是架构选错了，不用急着换系统，回去重新挑二进制就行。还有一种情况：同样的文件在旧内核上跑不起来，那是内核版本太老，和新版nmon的glibc要求有关。我在老旧的CentOS 6上就遇到过，后来换用发行版仓库里的旧版nmon才跑通。所以生产环境锁定一个验证过的版本，比每次都用最新版更稳。
3. 交互界面怎么用：按对键，几分钟看清问题方向
3.1 记这几个按键，实时排查够用了
nmon启动后是一个字符终端界面，底部有按键提示。使用它的门槛极低，核心按键就那么几个，记熟之后基本可以盲操作。
| 按键 | 功能 | 说明 |
|---|---|---|
| c | CPU状态 | 连续按会在整体平均和每个逻辑核之间切换 |
| m | 内存状态 | 可以查看物理内存、缓存和交换分区 |
| d | 磁盘状态 | 看每块磁盘的busy率、读写速率 |
| n | 网络状态 | 查看网络接口的实时吞吐 |
| t | 进程列表 | 按资源占用排序，类似top的进程视图 |
| j | 文件系统 | 查看挂载点和文件系统使用率 |
| q | 退出 | 退出nmon |
| 空格 | 手动刷新 | 立即刷新一次当前画面 |
| 左右方向键 | 调整刷新间隔 | 调大间隔可以降低对系统的影响 |
这里特别推荐熟练掌握连续按c的切换逻辑。24核以上的机器，默认按核显示会刷出密密麻麻一大片，想快速判断整体负载时，再按一次c切到平均值视图，清爽很多。同理，m键也有多级视图，可以在总览、详细内存分配之间切换。
3.2 带你看一遍数据库慢响应的排查过程
举个例子，假设一台数据库服务器突然响应变慢，我登录后启动nmon：
- 按c看到几个核的User%直接拉到90%以上，初步判断是计算型瓶颈，不是IO等待；
- 按m确认内存还有余量，Swap使用为0，排除内存换页；
- 按d看磁盘busy，发现虽然有一些波动但整体不高；
- 按n看网络流量，曲线平稳，没有异常尖峰；
- 最后按t看进程列表，定位到是哪个进程在持续消耗CPU。
整个过程五分钟就能下结论。如果换成top来回切，光是确认CPU、内存、磁盘、网络、进程这五个维度，可能就要反复按好几轮快捷键，而且每次看到的时间点还不一致。nmon的价值就在这里：一个屏幕里能把多个维度串起来，形成因果链，而不是给你一堆孤立的数据点。
4. 后台采数模式：真正的自动化运维核心玩法
4.1 参数组合与时长换算，一眼就能看明白
交互界面适合现场排查，但nmon真正的威力是后台采集。这个模式下，nmon不需要终端前台运行，把采样数据持续写入文件，事后统一分析。参数设计得很直观：
-f：以标准格式输出到文件，文件名默认是“主机名_日期_时间.nmon”；-s：采样间隔，单位是秒；-c：采样次数；-m：指定输出目录；-F：指定输出文件名；-t：采集线程级数据，抓进程内线程时用得上。
比如nmon -f -s 5 -c 720 -m /var/log/nmon，就是每5秒记录一次，共720次，持续时间正好60分钟。总时长很好算：间隔秒数乘以次数。
| 采样间隔 | 采样次数 | 实际覆盖时长 | 适用场景 |
|---|---|---|---|
| 10秒 | 360 | 1小时 | 故障复盘、压测分析 |
| 30秒 | 2880 | 24小时 | 日常巡检留证 |
| 60秒 | 1440 | 24小时 | 长期低频采集 |
采样间隔越短，数据越细，文件也越大。排查故障时我倾向用5到10秒的间隔，最好控制在1小时以内，保证细节完整又不至于文件膨胀。做长期巡检时可以放宽到30秒或60秒，文件体积和细节密度之间比较平衡。
4.2 接进crontab之前要想清楚的问题
后台采集要自动化，最自然是接进crontab。但直接甩一条crontab命令上去会埋不少雷，我建议用一个包装脚本统一处理。脚本里至少要做三件事：创建输出目录、避免重复进程、定期清理旧文件。
下面这个脚本是我常用的模板：
#!/bin/bash # nmon_collect.sh NMON_DIR=${NMON_DIR:-/var/log/nmon} SAMPLE_SEC=${SAMPLE_SEC:-10} SAMPLE_COUNT=${SAMPLE_COUNT:-720} mkdir -p "$NMON_DIR" # 避免同时跑多个nmon进程 if pgrep -x nmon > /dev/null 2>&1; then echo "nmon already running, skip." exit 0 fi nmon -f -s "$SAMPLE_SEC" -c "$SAMPLE_COUNT" -m "$NMON_DIR" # 清理30天前的采集文件 find "$NMON_DIR" -name '*.nmon' -mtime +30 -deletecrontab里加一条：
0 22 * * * /usr/local/bin/nmon_collect.sh这个例子是每天晚上22点启动采集两小时，正好覆盖常见的夜间任务高峰期。如果希望全天覆盖，可以把SAMPLE_SEC=30、SAMPLE_COUNT=2880，但要注意单次文件可能涨到几十MB，磁盘空间和后续分析都会受影响。脚本里的pgrep检查是实际运维中必须的，nmon本身没有防重复机制，crontab里时间重叠或者手动多跑了一次，就会出现多个nmon进程同时写文件，轻则文件混乱，重则磁盘被撑爆。
5. 分析数据：从.nmon文件到瓶颈定位
5.1 nmon analyser出报告的基本流程
采集完的.nmon文件不会自己说话，它内部是一行行带标签的文本记录。最常用的分析方式是配合nmon analyser这个Excel分析工具。
基本流程是：下载对应的xlsm格式分析模板，用Excel打开并启用宏，点击分析按钮，选择.nmon文件，等待几十秒，它就会生成一大堆带图表的sheet。整个流程不需要编写任何脚本，甚至不需要懂数据结构。对我来说，最重要的几个sheet是这样的：
- CPU总览sheet：看整机CPU使用率曲线，重点观察Wait占比；
- 内存相关sheet：看物理内存、缓存、Swap的变化趋势；
- 磁盘分析sheet：看磁盘busy率和读写吞吐；
- 网络sheet：看网卡流量是否异常。
这套分析工具最适合复盘“说不清原因”的偶发问题。图表可以缩放到某一时间窗口，和业务侧的报障时间做比对，因果关系一下就清晰了。
5.2 没有Excel时，用命令行也能查
生产环境分析不一定有Windows + Excel的环境。没有分析器的时候，直接看nmon文件里的文本行也能得到不少信息。nmon文件里每个指标域都有固定标签，比如CPU_ALL、MEM、DISKBUSY、NET等。你可以用grep快速提取：
grep "CPU_ALL" 主机名_20250101_2200.nmon | tail -20这条命令会输出最近20条CPU整体采样记录，每行包含一段时间的CPU使用率数据。虽然没有图表直观，但用来快速确认“某个时间段CPU到底高不高”足够了。稍微复杂一点的需求，可以配合awk或者python pandas做简单统计。这个命令行提取的思路，在很多临时环境里比Excel方便得多。
5.3 一次磁盘IO瓶颈的完整复盘
讲一个我印象很深的案例。某应用每天凌晨跑批，业务侧反馈凌晨两三点经常卡顿，但白天完全正常。当时在应用服务器上做了后台采集，覆盖凌晨零点到上午十点。
数据分析时，先看CPU总览sheet，发现用户态CPU使用率整体不高，但Wait占比在凌晨两点到三点期间持续走高。这时候CPU等待的指向已经很明确了，接下来切到磁盘分析sheet，看到一块数据盘在同一个时间段busy率接近100%，同时DISK READ曲线同步拉起。真相是跑批任务大量读同一块盘，磁盘本身的IO吞吐到了上限，CPU只能排队等IO。
后来把跑批程序的部分读操作挪到另一台机器的磁盘上，同一时间段的Wait占比立刻降了下来。整个过程的关键是：nmon把凌晨的IO尖峰完整记录下来了。如果没有后台采数，这个发生在深夜的瓶颈根本没法事后复盘——你总不能一宿不睡盯着top刷新。
6. 生产环境踩过的坑和我的处理习惯
6.1 采样周期与文件大小的平衡
用nmon时间长了，最容易忽略的是文件体积问题。之前图省事，用5秒间隔加线程采集开了一整天，第二天一看，单个.nmon文件接近上百MB。文件大带来的连锁反应是：nmon analyser打开极其缓慢，Excel甚至直接卡死，想分析的数据反而提取不出来。
我现在的原则是场景分离：日常巡检用30秒或60秒间隔，不开启线程采集；故障复盘的专项采集才用5秒到10秒间隔，并加上-t线程参数，但时长控制在1小时以内。这样既能保住关键细节，也不会把分析工具拖垮。
6.2 时区显示不一致的问题
跨时区分析nmon文件时，有一个很容易踩的坑：服务器生成的文件里记录的是服务器本地时间，但把文件拷回本地用Excel分析时，如果分析环境按UTC解析时间，图表的横轴会和事故实际发生时间对不上。我见过同事对着图表找半天找不到故障点，最后发现时间轴差了8小时。
处理办法很简单：分析前先确认服务器时区，在文件名或归档目录上标注清楚时区信息；如果分析工具支持时区设置，先设置成服务器所在时区再打开。这个细节不解决，再好的数据也白搭。
6.3 内存指标要结合Swap判断，别被free吓到
看nmon内存界面时，刚开始用的人很容易被“Used很高”吓到。其实Linux会尽量把空闲内存拿去当缓存，这是正常行为，不是内存泄露。判断内存是否真的紧张，我的习惯是：一看Swap使用率有没有持续上涨，二看内存曲线是不是单边爬升不回落。如果Swap一直是0，说明物理内存还够用；如果缓存曲线和进程占用同时稳步上升，应用本身吃内存的嫌疑就大了。
我还习惯把nmon的数据和系统里的free输出做对照。free命令显示的used是包含了cache的，看起来经常很高；而nmon把物理内存、缓存、缓冲分开展示，结合文件系统缓存的情况才能得出真实结论。这个差异在实际问题定位中经常会误导人。
6.4 版本选择和跨环境差异
nmon的Linux主流版本主要靠SourceForge更新，发行版仓库里的版本往往滞后。滞后不一定是坏事，至少经过了发行版的测试，但如果遇到新内核或者新CPU特性，老版本可能识别不完整。我现在的策略是：每台服务器锁定一个已验证过的版本，不追新，也不随便降级；批量部署时对二进制做一次sha256校验，避免下载过程中出现损坏或被人替换。
跨发行版使用时还会遇到一个现象：同样的nmon版本，在CentOS和Ubuntu上部分显示字段可能略有差异，尤其是在终端分辨率不够或编码不对时，画面会乱掉。遇到界面出现乱码，先检查终端字符集，再考虑版本问题，不要一上来就换文件。
最后分享一个小技巧：nmon这种采集方式不要等到故障发生了才想起来开。完全可以纳入日常运维计划，每月挑几天做定期采集，把数据归档保留。以后做容量规划、扩缩容决策时，这些历史数据比拍脑袋估算靠谱得多。我这边已经把nmon采集和值班巡检流程绑在一起，自动归档、定期清理，遇到“查无对证”的性能投诉，先翻这个月的nmon目录，多半能找到答案。
