1. 为什么性能测试绕不开 nmon 这个工具做性能测试这些年我越来越觉得压测本身其实只是整个链条里最轻的一环。真正吃功夫的是压测过程中对服务器资源的持续观测和事后分析。你脚本写得再漂亮并发模型设计得再合理如果压测跑起来之后你两眼一抹黑不知道 CPU 到底被谁吃掉了、内存是不是在缓慢泄漏、磁盘 IO 有没有成为瓶颈那这次压测基本等于白跑。我见过太多团队压测报告里只有 TPS 和响应时间两条曲线一问服务器资源情况全靠感觉还行来回答这种报告拿去做容量规划基本是给自己挖坑。nmon 就是在这个环节里被反复验证过的一个老牌工具。它的全称是 Nigels Monitor最早由一位工程师为 AIX 系统开发后来移植到了 Linux 平台。它最大的特点就是轻和全——一个二进制文件丢到服务器上就能跑不需要安装一堆依赖采集的时候对系统本身的性能影响极小同时又能把 CPU、内存、磁盘、网络、文件系统、进程等一大堆指标按固定频率记录下来最后生成一个结构化的数据文件配合分析工具就能出图。对于性能测试场景来说这几乎就是量身定做的压测期间持续采集压测结束后离线分析既不影响被测系统又能拿到完整的资源画像。这篇文章我想聊的不是nmon 是什么这种说明书级别的内容而是把它放到性能测试这个具体场景里讲讲我是怎么用它做监控的、采集频率怎么定、指标怎么看、数据怎么分析、踩过哪些坑。适合正在做性能测试、需要给压测结果配上资源监控数据的同学也适合那些平时用 top、vmstat 手动看指标、想升级到自动化采集的朋友。哪怕你之前完全没用过 nmon跟着走一遍也能上手。2. nmon 监控方案的整体设计与选型考量2.1 为什么在众多监控工具里选 nmon性能测试期间的服务器监控市面上能选的方案其实不少。粗略分一下大概有这么几类一类是重量级的监控平台比如各种时序数据库加采集代理加可视化面板的组合一类是系统自带的命令行工具比如 top、vmstat、iostat、sar还有一类就是 nmon 这种轻量级的单文件采集工具。重量级平台功能确实强大能长期存储、能告警、能多机聚合但放到性能测试这个场景里它有两个明显的短板。第一是部署成本高压测环境往往是临时搭建的为了跑一次压测去部署一整套监控体系投入产出比不划算。第二是采集代理本身会消耗资源虽然通常不大但在做极限压测、想摸清系统天花板的时候任何额外的资源消耗都可能影响结果的准确性。系统自带的命令行工具倒是零成本但它们都是瞬时快照式的你敲一下它给你看一眼想持续记录就得自己写脚本定时抓取再拼接麻烦且容易出错。而且不同工具输出的格式五花八门事后想统一分析很费劲。nmon 恰好卡在中间单文件、零依赖、采集开销极低、输出格式统一、自带分析工具。它不追求长期存储和告警就是专注做好压测期间把资源数据完整记下来这一件事。这种定位上的克制反而让它在性能测试场景里特别顺手。我的经验是短期压测用 nmon长期容量趋势监控用平台两者不冲突各司其职。2.2 采集方案的核心设计思路用 nmon 做性能测试监控整体思路可以概括成三段式压测前准备、压测中采集、压测后分析。压测前要做的是把 nmon 二进制文件传到目标服务器上确认能正常执行然后规划好采集频率和输出路径。这里有个容易被忽略的点nmon 采集的数据文件是持续写入的如果压测时间很长、采集频率很高文件会变得很大所以要提前确认磁盘空间够用最好把输出目录放在一个独立的、不会被压测本身大量写入的分区上避免互相干扰。压测中nmon 以守护进程的方式在后台跑按设定的频率往文件里追加数据。这个阶段基本不用管它但要注意别让压测脚本或者运维操作误删了数据文件。压测后把数据文件拉回本地用分析工具生成图表或者导出成表格再结合压测的 TPS、响应时间曲线做交叉分析。这一步才是真正产生价值的地方——单看资源曲线没意义只有把它和业务指标对齐才能回答这个瓶颈到底卡在哪。2.3 采集频率与监控粒度的权衡采集频率是这套方案里最需要动脑子定的参数。nmon 支持的最小采集间隔是 1 秒但并不是越密越好。频率太高比如 1 秒一次数据文件会迅速膨胀。假设你压测 2 小时1 秒采集一次那就有 7200 个采样点每个采样点包含几十个指标文件大小轻松上百兆。而且这么密的采样很多指标的变化其实是被噪声主导的看起来反而乱。频率太低比如 60 秒一次又会漏掉很多短时的尖峰。性能测试里最怕的就是那种持续几秒的毛刺比如 GC 导致的 CPU 突增、某个慢查询导致的 IO 抖动60 秒的粒度根本抓不住。我的经验值是常规压测用 5 到 10 秒一次比较均衡如果压测时间很短比如 10 分钟以内或者专门想抓瞬时尖峰可以调到 1 到 2 秒如果是长达数小时的稳定性测试10 到 30 秒也够用。这个没有标准答案取决于你想回答什么问题。想清楚我要抓什么现象频率自然就定了。3. nmon 核心指标解读与实操要点3.1 CPU 指标别只盯着一个使用率nmon 的 CPU 部分会给出好几个维度的数据很多人只看一个总的 User% 或者 Sys%这是不够的。我一般会重点关注这几个User%用户态 CPU 占用通常反映应用本身的计算量。如果这个值很高说明应用在拼命算东西可能是算法效率问题也可能是请求量确实大。Sys%内核态 CPU 占用反映系统调用的开销。这个值异常高往往意味着频繁的系统调用、上下文切换或者 IO 操作太密集。Wait%等待 IO 的 CPU 时间占比。这个指标特别关键它高说明 CPU 其实在空等磁盘或网络瓶颈不在 CPU 而在 IO。很多人看到 CPU 使用率不高就以为没问题其实 Wait% 已经把真相说出来了。Idle%空闲占比这个最直观但单独看意义不大。上下文切换和中断nmon 也会记录频繁的上下文切换往往是锁竞争或者线程模型有问题的信号。实操上有个小技巧nmon 的 CPU 数据是按所有核心汇总的如果你的服务器核心数很多单个核心被打满的情况在汇总数据里可能被稀释。这时候要结合每核心的数据来看或者干脆在压测时用绑核的方式把压力集中到少数核心上观察更清晰。3.2 内存指标关注趋势而非绝对值内存这块nmon 会给出总内存、空闲内存、缓存、缓冲、Swap 使用等数据。看内存最忌讳的就是只看某一时刻的绝对值因为 Linux 的内存管理机制决定了它会尽量把空闲内存拿去做缓存所以空闲内存少本身不是问题。真正要关注的是趋势和 Swap。如果压测过程中空闲内存持续下降、缓存被不断挤压最后开始动用 Swap那就是危险信号了。Swap 一旦被大量使用性能会断崖式下跌因为磁盘的速度和内存差了好几个数量级。我在压测里见过好几次前半小时一切正常一小时后响应时间突然飙升回头一看内存曲线Swap 在某个时间点开始猛涨原因就是应用有内存泄漏压测时间一长就露馅了。所以看内存我习惯把整个压测周期的曲线拉出来看它是不是平稳有没有单调上升的趋势。平稳说明内存使用健康单调上升就要警惕泄漏。3.3 磁盘与网络指标定位 IO 瓶颈的关键磁盘部分nmon 会给出每个磁盘设备的读写速率、IOPS、平均等待时间、繁忙度等。这里最值得看的是平均等待时间和繁忙度。等待时间高说明 IO 请求排队严重繁忙度接近 100% 说明磁盘已经跑满。如果这两个指标在压测中持续高位那磁盘就是瓶颈再怎么优化应用代码也没用得从存储层面想办法。网络部分nmon 记录的是每个网卡的收发速率和包量。这里要注意区分带宽瓶颈和包量瓶颈。有时候带宽没跑满但包量很大小包太多导致 CPU 花大量时间处理网络中断这种情况在汇总的带宽数据里看不出来得结合包量和 CPU 的 Sys% 一起判断。提示磁盘和网络指标一定要结合业务逻辑看。比如一个读多写少的服务磁盘写速率突然飙升那大概率是日志打太多了而不是业务本身的问题。3.4 采集过程中的注意事项nmon 虽然轻但用的时候有几个坑得避开。第一输出文件路径要选对。默认它可能写到当前目录如果当前目录正好是被压测应用频繁读写的地方会互相干扰。我一般会指定一个专门的目录比如/tmp/nmon_data或者独立的数据盘。第二采集进程本身要确认存活。nmon 在后台跑万一因为磁盘满、权限问题或者被误杀而退出你可能压测跑完了才发现数据没采到。我的做法是在压测脚本里加一个检查压测开始后确认 nmon 进程在压测结束前再确认一次。第三时间同步。nmon 记录的时间戳是基于服务器本地时间的如果你要把它和压测工具可能在另一台机器上的记录对齐两台机器的时间必须同步。这个细节很小但对齐不上时间的时候能让人抓狂。第四别在压测中途改采集参数。nmon 启动后参数就固定了中途想改只能重启重启会导致数据文件出现断层分析的时候很麻烦。所以参数一定要在压测前想清楚。4. 完整实操流程与关键环节实现4.1 环境准备与工具部署nmon 的部署简单到几乎不需要部署这个词。它就是一个编译好的二进制文件对应不同的 Linux 发行版和 CPU 架构有不同的版本。你需要根据目标服务器的系统版本和架构选对文件然后传上去、加执行权限就行。# 假设已经把对应版本的 nmon 文件传到服务器上 chmod x nmon_x86_64_rhel8 # 改个短名字方便调用 mv nmon_x86_64_rhel8 nmon # 验证能否执行 ./nmon -h如果执行后能看到帮助信息说明环境没问题。如果报错说找不到某个库那通常是版本不匹配换一个对应系统的版本即可。这一步看着简单但我确实遇到过有人传错架构的文件折腾半天以为是权限问题。4.2 启动采集与参数配置nmon 的采集模式通过命令行参数控制最常用的几个参数我列一下参数含义常用取值-f以文件模式采集输出到文件必选-s采集间隔单位秒5 或 10-c采集次数根据压测时长计算-m输出目录独立数据目录-t包含 top 进程信息建议开启-T记录命令行参数排查时有用采集次数和压测时长的关系要算清楚。比如压测计划跑 30 分钟采集间隔 10 秒那采集次数就是 30×60÷10 180 次。但实际配置时我一般会多给一些余量比如配 200 次防止压测因为准备或收尾多花了几分钟导致数据不够。启动命令大概长这样./nmon -f -s 10 -c 200 -m /tmp/nmon_data -t这条命令的意思是以文件模式采集每 10 秒一次共 200 次输出到/tmp/nmon_data目录同时记录 top 进程信息。启动后它会立刻转入后台你可以用ps确认一下进程在不在。注意-t 参数会额外记录进程级别的数据对定位到底是哪个进程在吃资源非常有用但会让文件变大一些。压测场景我强烈建议开启因为事后你很可能需要知道是应用进程还是别的什么进程在消耗资源。4.3 压测期间的数据采集与监控nmon 启动之后压测就可以开始了。这个阶段你要做的是确保采集不中断同时记录一些关键的上下文信息。我习惯在压测开始和结束的时候各记一个时间点比如用date命令输出当前时间写进压测日志。这样事后分析的时候能准确知道哪一段数据对应压测的哪个阶段。别小看这个动作没有它你面对一堆数据文件根本不知道从哪看起。另外如果压测分多个阶段比如阶梯加压每个阶段的起止时间也要记下来。nmon 的数据是连续的但你的分析需要按阶段切分有了时间标记切分就是几秒钟的事。压测过程中还可以顺手用top或者vmstat快速扫一眼看看有没有明显异常。nmon 是事后分析用的实时性不如这些命令。两者配合一个负责记录一个负责即时观察。4.4 数据文件导出与离线分析压测结束后先确认 nmon 进程已经正常退出采集次数跑完会自动退出然后把数据文件拉回本地分析。nmon 生成的文件是.nmon格式本质上是文本但直接看很费劲需要配合分析工具。分析工具有两种主流选择。一种是 nmon 官方配套的分析器通常是一个 Excel 宏文件把.nmon文件拖进去就能自动生成各种图表。这种方式直观适合快速出报告。另一种是自己写脚本解析把数据转成 CSV 再用 Python 或者别的工具画图。这种方式灵活适合需要定制化分析或者集成到自动化流程里的场景。我个人的习惯是日常快速看用 Excel 分析器正式报告或者需要和其他数据交叉分析的时候用脚本。Excel 分析器的好处是零门槛坏处是数据量大时会卡而且图表样式不太好看。用脚本解析的话.nmon文件的格式是有规律的每个采集周期会有一个时间戳行后面跟着各个子系统的数据块。解析的时候按时间戳切分再按子系统提取字段就行。网上有不少现成的解析脚本可以参考核心逻辑都不复杂。4.5 资源数据与业务指标的交叉分析拿到资源曲线之后最关键的一步是把它和业务指标对齐。具体做法是把压测的 TPS、响应时间曲线和 nmon 的资源曲线画在同一时间轴上然后观察它们之间的相关性。举几个典型的对应关系。如果 TPS 上不去同时 CPU 的 User% 已经打满那瓶颈在 CPU 计算能力考虑优化算法或者加机器。如果 TPS 上不去CPU 不高但 Wait% 很高磁盘繁忙度也高那瓶颈在 IO考虑换 SSD 或者优化读写。如果响应时间随压测时间缓慢上升同时内存空闲持续下降、Swap 开始增长那大概率是内存泄漏得去查代码。这种交叉分析才是性能测试监控的真正价值所在。单看资源数据你只知道CPU 用了 80%但结合业务数据你才能说CPU 用了 80% 导致 TPS 卡在 5000 上不去。前者是现象后者是结论。5. 常见问题与排查技巧实录5.1 nmon 采集数据为空或不完整这是最常见的问题表现是压测跑完了打开数据文件发现只有寥寥几行或者干脆是空的。原因通常有这么几个一是采集次数配少了压测还没结束 nmon 就采完退出了。这个最好排查看看文件里的时间跨度是不是明显短于压测时长。二是输出目录没有写权限nmon 启动时可能没报错但实际写不进去。检查一下目录权限或者换个目录试试。三是磁盘满了写到一半写不进去了。这个在长时间压测里比较常见尤其是输出目录和压测数据在同一个分区的时候。四是 nmon 进程被误杀。有些运维脚本或者清理任务会杀掉不明进程nmon 可能中招。压测前和运维打个招呼把 nmon 加进白名单。排查的时候先看文件大小和时间跨度再看目录权限和磁盘空间最后确认进程有没有异常退出。按这个顺序基本能定位。5.2 采集频率与实际需求不匹配有时候压测跑完了分析的时候才发现采集频率定得不合适。要么太密数据文件巨大分析工具打开就卡死要么太疏关键的尖峰全被平滑掉了。这个问题没有事后补救的办法只能压测前想清楚。我的建议是如果不确定宁可稍微密一点。因为数据密了可以降采样但数据疏了没法凭空补出来。当然也别密到 1 秒一次跑几小时那样文件会大到没法处理。一个折中的做法是正式压测前先跑一个短时间的预压测用同样的频率采集看看数据文件大小和指标变化情况再决定正式压测用什么频率。这个预压测花不了多少时间但能避免很多返工。5.3 指标异常但找不到对应进程有时候你会看到 CPU 或者内存异常但不知道是哪个进程干的。这时候-t参数记录下来的 top 进程信息就派上用场了。它会记录每个采集周期里资源占用最高的几个进程你顺着时间点去找基本能锁定元凶。如果开了-t还是找不到那可能是资源被内核态消耗了比如中断处理、内核线程。这种情况要看更底层的指标比如中断次数、软中断分布。nmon 对这些也有记录但需要你对 Linux 内核有一定了解才能解读。还有一种可能是资源被容器或者虚拟化层消耗了。如果压测环境跑在容器里nmon 看到的是宿主机视角的数据容器内的进程可能对不上。这种情况需要在容器内单独采集或者用 cgroup 的数据来对照。5.4 时间戳对不齐导致分析困难前面提过时间同步的问题这里展开说一下。nmon 的时间戳是服务器本地时间压测工具的时间戳可能是另一台机器的本地时间。如果两台机器时间差了几分钟你把两条曲线画在一起就会发现它们错位了分析结论可能完全错误。解决办法很简单压测前用 NTP 把相关机器的时间同步一下。如果环境不允许那至少在压测开始和结束时在两台机器上各记录一次时间事后手动计算偏移量来校正。这个动作花不了一分钟但能省掉后面几小时的困惑。5.5 常见问题速查表问题现象可能原因排查方向数据文件为空权限不足、磁盘满、进程被杀检查目录权限、磁盘空间、进程状态数据不完整采集次数不足、中途退出核对采集次数与压测时长、查看进程退出原因文件过大采集频率过高、压测时间过长降低频率、分段采集指标异常找不到进程未开 -t、内核态消耗、容器环境开启 -t、查看中断数据、容器内单独采集曲线对不齐时间未同步压测前 NTP 同步、记录起止时间校正分析工具卡死数据量过大降采样、分段分析、改用脚本解析5.6 几个压箱底的实操心得说几个文档里不会写、但实际用起来很关键的点。第一压测前先做一次空跑。不施加压力只开 nmon 采集几分钟看看基线数据长什么样。有了基线压测中的数据才有参照你才能判断哪些变化是压测引起的哪些是系统本来就有的波动。第二数据文件多备份一份。压测数据往往是一次性的环境可能随时被回收。采集完立刻把文件拷到安全的地方别等到要分析的时候发现文件没了。我吃过这个亏后来养成了压测一结束就备份的习惯。第三分析时先看全局再看局部。一上来就盯着某个时间点的细节很容易迷失。先把整个压测周期的曲线扫一遍找出异常的时间段再放大看细节。这个顺序能帮你快速定位问题而不是在数据海洋里瞎转。第四把 nmon 采集纳入压测脚本自动化。手动启动 nmon 容易忘也容易出错。把启动、检查、停止、导出这一套写成脚本和压测流程绑定每次压测自动执行。这样既保证了数据不缺失也省去了重复劳动。6. 从单次监控到体系化能力nmon 用熟了之后你会发现它不只是一个采集工具而是一套可以沉淀的方法论。单次压测的监控数据如果只是用完就扔那价值有限。但如果把每次压测的资源数据都归档下来时间长了就能形成一套基线库。下次压测的时候拿新数据和历史基线一对比系统有没有退化、容量有没有变化一目了然。再进一步可以把 nmon 的采集和分析集成到持续集成流程里。每次版本发布前跑一轮基准压测自动采集资源数据、自动生成对比报告一旦发现资源消耗明显上升就卡住发布。这种体系化的能力比单次压测时手忙脚乱地看指标要有价值得多。我自己在实际操作中的体会是性能测试的监控这件事工具只是载体真正决定效果的是你有没有想清楚我要回答什么问题。nmon 能给你海量的数据但数据本身不会说话是你带着问题去分析它才变成有用的信息。所以每次压测前我都会先问自己这次压测我最想搞清楚的是什么是 CPU 瓶颈、内存泄漏还是 IO 天花板想清楚了采集参数怎么定、数据怎么看自然就清晰了。最后再分享一个小技巧nmon 的数据文件其实可以直接用文本编辑器打开看虽然格式不友好但在紧急情况下比如分析工具打不开你可以用grep快速搜某个时间点的数据或者用awk提取某一列做简单统计。这个技能在排查突发问题的时候特别管用不用等分析工具几行命令就能看出个大概。