企业官网建设流程全解析

1. 项目概述与工具定位

1.1 为什么还需要一款"老牌"监控工具

做过Linux运维的朋友应该都有这种感觉：系统监控工具多得眼花缭乱，从系统自带的top、vmstat、iostat，到后来崛起的Prometheus+Grafana组合，再到各种Agent采集方案，几乎每个团队都有自己的"监控全家桶"。但真要排查一台机器的临时性能问题，或者是面对一台没装任何Agent的新服务器，我却总是会第一时间打开nmon。

nmon全称是Nigel's Monitor，由IBM的Nigel Griffiths开发，最早是自家AIX系统上的工具，后来移植到Linux平台。它最让我服气的一点，就是几十年下来始终保持着"单文件、零依赖、开箱即跑"的风格。你不需要安装一堆Python包，不需要初始化数据库，不需要配置采集端点，只需一个二进制文件丢到服务器上，立即就能看到CPU、内存、磁盘、网络、进程等十几类指标的实时变化。

很多新手会问：既然top已经能看CPU和内存，iostat能看磁盘，sar能历史回溯，为什么还要单独用nmon？我的答案是：nmon把散落在一堆命令里的指标全部归到了一张字符界面上，而且它自带一套高性能的数据记录能力，能在高负载场景下以极低开销持续采样，最后还能把数据导出成Excel可读的分析文件。这对于临时救火、性能测试、上线前压测巡检来说，效率非常高。

1.2 这篇博文适合谁

如果你属于以下任一种情况，这篇内容应该能帮到你：

• 刚接触Linux运维，想在top之外掌握更系统的性能排查方法。
• 需要在不安装额外重型监控系统的情况下，快速定位CPU飙升、内存泄漏、磁盘IO异常等问题。
• 做性能测试或容量评估，需要记录一段时间内的服务器各项指标变化趋势。
• 团队要求输出性能分析报告，但不知道如何把终端里的监控数据整理成直观图表。

我接下来的内容会从nmon的基本使用、核心指标解读、数据记录与导出，到生产环境下的实践心得、坑点排查，完整过一遍。不会堆太多参数手册，重点讲清楚"为什么要这样用"以及"我在实际环境中遇到过什么"。

2. nmon的核心能力与设计思路拆解

2.1 为什么它能"一个命令看全局"

先上一段最基础的操作：登录Linux服务器后，直接执行nmon，屏幕上会实时刷新一台机器的整体状态。页面默认不显示任何图表，你需要通过快捷键打开关心的指标区域，常用的按键如下：

• c：CPU利用率，显示每个核心的使用率、等待率、空闲率。
• m：内存使用情况，包含物理内存、虚拟内存、页交换等关键数据。
• d：磁盘组信息，按磁盘设备展示读写速率、IO占有率、平均等待时间等。
• n：网络状态，包含每块网卡的收发速率、包量、错误包数。
• j：文件系统使用率，类似df -h的效果，但更贴近系统缓存视图。
• t：系统最耗资源的Top进程列表。
• k：内核统计信息，如上下文切换、运行队列长度等。
• h：帮助页面，按h即可看到所有快捷键。

这里有一个设计上的关键点：nmon默认不开图表，是因为它希望"按需加载"。系统指标采集本身有开销，如果你从来不看网络状态，那就没必要每秒钟都去轮询/proc/net/dev。这种设计在性能敏感的生产环境里非常重要——监控工具本身不能成为系统的性能负担。

从架构角度来看，nmon的数据来源基本就是Linux内核的/proc文件系统和/sys文件系统，它把内核暴露的计数器快照转换成人类可读的指标。因为读取的都是内核实时统计信息，所以不需要额外占据多少内存或CPU。官方资料和第三方测评都显示，默认每秒采样一次，nmon自身的CPU占用率通常在0.1%以下，这在压测场景里完全可以忽略。

2.2 实时界面与数据录制双模式

nmon最容易被忽略的点是：它其实是"双模式"工具。

第一种是交互模式，就是上面说的实时全屏界面，适合你坐在终端前观察系统状态变化。比如压测过程中，你可以盯着屏幕看CPU是否被打满、磁盘是否出现瓶颈、网络是否有丢包。

第二种是数据录制模式，用-f或者-s、-c参数组合，让nmon在后台把采样数据持续写入文件。比如执行：

nmon -f -s 5 -c 120

这条命令的含义是：立即开始采样，每5秒记录一次，总共记录120次，也就是持续10分钟。生成的文件名类似HOSTNAME_日期_时间.nmon。之后可以用配套的nmon analyser工具，把.nmon文件导入Excel，自动生成CPU、内存、磁盘、网络等几十张图表。

这两种模式解决的问题完全不同：交互模式回答的是"现在发生了什么"，录制模式回答的是"过去一段时间发生了什么"。我在实际工作中，既会启动压测时用录制模式全量留痕，也会在怀疑某一时刻异常时手动打开交互界面去"现场抓拍"。

2.3 搭配nmon analyser，把数据变成图表

nmon本身是字符界面，直接看数据也可以，但人脑对数字的感知远不如对趋势图敏感。这里要介绍nmon生态里的黄金搭档——nmon analyser。它是一个Excel宏工具，由IBM开发，社区持续维护。你从网站下载nmon analyser的xlsm文件后，用Excel或WPS打开，点击"Analyse nmon data"按钮，选择刚才生成的.nmon文件，它就会自动把整个采样周期内的数据转换成图表。

图表里最常用的几个：

• CPU Average：整机CPU使用率、I/O等待率趋势。
• Memory：物理内存、虚拟内存、Swap使用量变化曲线。
• Disk Total：所有磁盘的读写MB/s、Busy%、平均IO响应时间。
• Network：各网卡的收发流量、错误包、丢包率。

这样一份图表，直接就能作为性能测试报告的支撑材料。我记得有一次客户反馈服务器"莫名其妙慢"，我让他录了一个小时的nmon数据，拿回办公室导入analyser一看，网络接收流量曲线中间有个明显的尖峰，再对应时间戳排查业务日志，发现是定时任务在整点拉取大量数据，问题很快就定位了。如果没有历史趋势数据，这种"时有时无"的故障非常难复现。

3. 环境准备与工具选型

3.1 从哪里获取nmon

nmon的官方网站托管在SourceForge上，项目名叫nmon for Linux，页面里会根据CPU架构区分不同版本的二进制包。主流Linux发行版也会有各自的软件仓库集成，比如：

• Debian/Ubuntu系列：apt install nmon
• RHEL/CentOS/Rocky/AlmaLinux系列：yum install nmon或dnf install nmon
• SUSE/openSUSE：zypper install nmon

用系统包管理器安装是最省事的方式，版本虽然可能不是最新，但胜在和系统兼容性好，依赖库也不会有问题。我平时第一反应就是直接yum或apt装，装不上才去官网下载。

在一些离线内网环境，或者追求最小化部署的场景，我更习惯用静态编译的独立二进制包。nmon的Linux版本通常不需要额外的运行库，下载后chmod +x nmon_x86_64_*，放到/usr/local/bin下，改个名就能全局使用。这比安装一堆依赖再配置服务省心得多。毕竟监控工具本身是为了解决系统问题，如果是装监控工具的过程中又引出一堆环境依赖问题，那无异于给病人做检查时反而把病人折腾出新的毛病。

3.2 ARM架构（aarch64）下安装的注意点

热搜词里出现了"nmon监控工具 arrch64"这样的组合，正好说明现在ARM服务器已经非常普及。国产芯片服务器、云上的ARM实例、Apple Silicon上的Linux虚拟机，都可能用到aarch64架构。很多新手直接下载x86_64版本，结果执行时报"Exec format error"，其实是架构不对。

判断服务器架构很简单：

uname -m

输出aarch64就是64位ARM架构，输出x86_64是Intel/AMD的64位架构。然后去下载对应nmon_aarch64_*版本即可。SourceForge上的发布目录里命名很清楚，别选错。

另外，nmon本身对内核和glibc有一定要求，老版本的Linux系统可能需要老版本的nmon才能运行。如果出现GLIBC_2.xx not found之类的报错，通常换一个更早的nmon发布版本就能解决。我在CentOS 6上装新版nmon时就遇到过这个问题，后来找到对应2016年的编译版本才跑起来。这一点在老旧生产服务器上特别有用。

3.3 为什么我不推荐在nmon之外再加一层"自动部署平台"

市面上有些运维平台会把nmon作为采集器集成进去，统一管理多台服务器的采集任务。这种思路不是不行，但要注意：平台本身可能自带Agent，Agent再去拉起nmon，两层采集同时运行，既浪费资源，又可能在故障排查时混淆数据来源。

我的建议是：nmon作为"轻量级单机巡检工具"使用，适合临时取证和性能压测；如果是长期、多节点的监控，就应该用Prometheus这类专业时序监控系统，而不是把nmon强行变成常驻服务。工具要放在合适的位置上，才能发挥最大价值。

4. 核心监控维度与参数解读

很多教程会直接丢出一堆快捷键和参数选项，但很少解释"这些数据到底说明什么"。我觉得这里非常值得展开讲清楚，因为监控的最终目的是定位问题，而不是把数据贴到工单里。

4.1 CPU维度：别只看"用了百分百"

nmon的CPU页面会把系统CPU时间、用户CPU时间、I/O等待时间、空闲时间分开统计。实际排障时，真正需要关注的是"CPU时间花在了哪里"：

• 用户态占比较高，通常是业务进程在大量计算，比如Java应用在做GC、Python脚本在跑循环。
• 系统态占比较高，说明内核态频繁活动，可能与系统调用过多、锁竞争、中断密集有关。
• I/O等待占比较高，但这个指标一定要慎读。CPU在等待磁盘或网络IO时显示为wiat，如果wait很高但CPU利用率并不高，说明进程都在等IO；如果CPU已经跑满且wait很高，说明IO是瓶颈之一，但不是唯一瓶颈。
• 运行队列长度（run queue）持续超过CPU核心数，说明系统已经过载，任务在排队等着被执行。

nmon对应页面上还有每个CPU核心的独立利用率视图。像Java这类多线程应用，如果发现只有某个核心打满，而其他核心很空闲，很可能是锁竞争或者单线程热点代码，这种问题在整机平均值里完全看不出来。

4.2 内存维度：Swap与页交换要分开看

nmon的内存页面把物理内存的各个部分拆得很细：Active、Inactive、Wired、Cache、Buffer、Swap。最容易误导新手的，是看到free -m里的"available"很小，就以为内存不够了。实际上Linux会尽量把空闲内存用作文件缓存，这些缓存随时可以回收给应用程序，所以真正需要关注的是Swap的使用和页交换速率：

• Swap占用持续升高，说明物理内存确实不足，部分冷数据被换到磁盘上。
• 页交换速率（page in/page out）出现高频跳动，即使Swap占用不涨，也可能是内存碎片或突发的内存申请导致。
• Cache居高不下通常不用管，除非要分析某个进程是否因为文件缓存被占用太多而无法申请到内存。

在nmon的录制文件里，Memory图表会清晰展示Free Memory和Cache/Buffer的变化趋势。比如压测过程中Free Memory阶梯式下降，之后没有回升，那大概率是Java堆或C++程序的内存泄漏；如果Free Memory一路见底且Swap曲线同步抬头，说明需要扩容物理内存或者调低应用的内存配置。

4.3 磁盘维度：IO延迟比速率更能反映体验

磁盘页面我最常看的是Busy%（磁盘忙碌百分比）和I/O平均等待时长。忙不忙是一个方面，等多久才是用户体验的直接体现：

• 磁盘读写MB/s高但Busy%很低，说明磁盘能力富余，应用大小IO在流畅运行。
• Busy%接近100%但MB/s不高，说明磁盘能力不足或IO队列堆积，应用访问磁盘会排长队。
• 平均IO等待时间（service time / await）明显上升，说明磁盘响应已经变慢，可能是磁盘坏道、RAID重建、或者后端存储网络抖动。

在压测场景里，如果数据库TPS上不去，同时nmon磁盘页面显示对应数据盘的Busy%恒满、await持续飙升，那结论就非常明确了：存储是瓶颈。这时候去调SQL、优化索引，效果都不会太明显，先解决存储再说。

4.4 网络维度：区分流量和错误

网络页面按网卡展示实时收发KB/s、包数量、错误计数和丢包统计。排查网络问题时要分两层：第一层看流量有没有跑满带宽，第二层看有没有TCP重传、错误包、丢包。

比如网卡显示收发速度都不高，但业务方反馈"很卡"，那大概率不是带宽问题，而是延迟或丢包问题。这时候我会在nmon网络页面紧盯Error和Drop列。如果你发现错误包在持续增长，很可能是网线质量差、网卡驱动异常、或者交换机端口故障。如果错误包为0但网络延迟高，那就要结合其他工具看链路质量了。

需要注意，nmon对网络指标的统计依赖系统网卡统计信息，有些虚拟化平台（比如容器网络、虚拟机桥接网络）的虚拟网卡计数可能和实际物理链路表现不一致。所以nmon网络数据适合作为基础参考，如果出现可疑趋势，还需要用ping、tcpdump去二次验证。

4.5 Top进程维度：从系统层面落到业务层面

按t键可以进入进程列表，按CPU或内存排序。这个功能在"系统负载莫名变高，但又不知道是谁干的"的场景下非常有用。抓进程的要点是：

• 先看CPU占用率，再看内存占用，然后再看该进程实际对应的业务服务。
• 高CPU占用不一定是坏事，可能是业务高峰；但如果出现在凌晨低峰期，就需要警惕定时任务、数据批量处理程序等"隐形杀手"。
• 高内存占用且长时间不释放，大概率是配置的内存上限太高或程序有泄漏。

有一次同事反馈服务器经常卡顿，我一登录nmon按t，看到一个java进程的CPU占用超过800%（多核累计），再对应CPU页面看，6个核心确实被打满了。通过jstack抓线程一看，是该项目的GC线程在其他线程持锁等待时疯狂自旋，导致CPU空转。如果没有nmon把"系统CPU满+Java进程线程异常"这两个线索串起来，单独看哪个指标都不容易定位。

5. 数据录制与自动化采集实操

5.1 录制模式参数详解

nmon录制模式是我最常用的功能，因为它能把性能问题变成"事后可查"。核心参数就是-s（采样间隔）、-c（采样次数）、-f（保存到文件）、-t（记录耗时数据）。

拿一个真实场景举例：客户说每天晚上8点系统会卡顿，持续约半小时。我通常这样操作：

nmon -f -s 30 -c 240 -m /opt/nmon_data

这里-s 30表示每30秒采一次样，-c 240表示采样240次，总时长30秒乘以240次，正好120分钟，也就是从晚上7点半记录到9点半，把晚上8点前后的一段完整覆盖。-m指定输出目录。生成的文件名类似localhost_220718_1930.nmon，里面已经包含了时间戳，方便后续对照。

在实际性能压测中，采样间隔要更密。比如压测持续10分钟，我会用-s 5 -c 120，5秒一次，120次，总共600秒。间隔太短会增大系统开销，间隔太长又可能错过瞬时毛刺。我自己的经验是：常规巡检采样间隔30秒到1分钟足够，压测场景5到10秒为宜，极端性能分析才会用到1秒间隔。

5.2 使用crontab实现定时采集

有些场景下，我们希望服务器在无人值守的时间段自动记录性能数据，比如凌晨的业务定时任务期间。这时候可以借助crontab来启动nmon。

先新建一个采集脚本，比如/opt/scripts/nmon_auto_collect.sh：

#!/bin/bash HOSTNAME=$(hostname) CUR_DATE=$(date +%Y%m%d_%H%M) /usr/bin/nmon -f -s 60 -c 120 -m /opt/nmon_data -F ${HOSTNAME}_${CUR_DATE}.nmon

然后添加crontab任务：

crontab -e

写入如下行，表示每天的23点30分开始自动录制一个小时的性能数据：

30 23 * * * /bin/bash /opt/scripts/nmon_auto_collect.sh

这样第二天早上就能直接去/opt/nmon_data/目录里取前一晚的性能快照，配合业务日志就能复盘凌晨时段的各种异常。定时采集的时间最好和业务低峰期、备份窗口、定时任务执行期对齐，这样才能在大事故过去之后找到当时的现场数据。

有一个坑我提醒一下：cron执行脚本时环境变量和交互式终端不一样。如果nmon不是放在/usr/local/bin或者/usr/bin下，而是你自建的/opt目录，脚本里务必写绝对路径，否则会报"command not found"。另外如果脚本里用到了hostname、date这类命令，也要注意它们在PATH中是否可用，最好都写绝对路径或者先export PATH。

5.3 录制文件的管理与归档

.nmon文件过几个月会积累很多，如果不加管理，目录会越来越乱。我的习惯是按日期分目录，每周归档一次到对象存储或备份服务器，保留最近30天的原始文件即可。因为在分析完成并生成报表后，原始.nmon文件只保留必要的周期用于追溯，不需要无限期堆砌。

文件名格式也很重要。我建议至少在文件名里带上主机名、日期、时间段，比如web01_20250118_1500.nmon。这样即使文件被拷贝到别的机器，也能一眼看出它是什么时候、哪台机器的数据。我见过有人录了一大堆文件，文件名全是localhost_...，后续分析时傻傻分不清来源，很耽误事。

6. 数据分析实战：把.nmon文件变成可视化报告

6.1 nmon analyser导入与生成图表流程

拿到.nmon数据文件后，最直观的分析方式就是用nmon analyser。步骤如下：

1. 打开Excel或者WPS，启用宏功能。第一次打开xlsm文件时，如果被禁用宏，需要在设置里允许启用。
2. 点击Excel菜单栏或页面上出现的"Analyse nmon data"按钮。
3. 选择你的.nmon文件，确认导入。分析过程可能需要几十秒到数分钟，取决于采样点数量。
4. 完成后，Excel会自动生成一个带有一批Sheet的工作簿，每个Sheet对应一类性能指标图表。

如果你所在的办公环境没有Excel，也可以用WPS的宏功能来打开，新版WPS已经支持大部分Excel宏。不过我还是建议使用Excel 2016及以上版本，兼容性最好。如果宏运行报错，常见原因是Excel安全设置阻止了宏，或者文件路径包含中文和特殊字符。把.nmon文件放到一个纯英文路径下，往往就能解决问题。

6.2 如何从图表中快速定位性能瓶颈

很多新手拿到生成的几十个Sheet会懵：到底该看哪张图？我的经验是分三步走：

第一步，看全局。先看CPU Average、Memory、Network Total这几张全系统层面的图表，确认瓶颈面到底在哪个子系统。如果CPU很忙，往计算方向排查；如果磁盘Busy%很高，往IO方向排查；如果网络曲线呈持续上升，再往下看具体网卡。

第二步，看子项。比如CPU图显示用户态整体占用很高，那就回看Top Processes，找出最吃CPU的进程；内存图显示Free Memory持续走低，就看哪个进程内存增长最快，结合业务日志判断是否泄漏。

第三步，叠时间线。把异常的指标曲线和业务事件时间线对齐，比如访问量高峰、定时任务执行、上线发版时间。这一步有时比数据本身更重要，因为很多性能问题只在特定事件触发时才会出现。

6.3 数据结论如何写进报告

一份合格性能分析报告，至少应该包含以下内容：

• 采集环境说明：主机配置、操作系统版本、nmon版本、采样时间范围。
• 指标概览：CPU、内存、磁盘、网络的峰值与平均值。
• 异常时间段：什么时间点出现异常，异常持续多久。
• 关联分析：异常期间有哪些业务动作，哪些进程表现异常。
• 后续建议：扩容、参数调整、业务削峰、代码优化等方向。

这其中的关联分析是最考验经验的环节，也是报告真正有价值的部分。数据本身不会告诉你"为什么会卡"，但它能帮你把问题范围从"系统很卡"缩小到"某段时间内某块磁盘等待时间持续超过50毫秒"，从而让后续排查有明确方向。

7. 生产环境使用技巧与常见问题排查

7.1 服务器没有外网，怎么处理nmon缺失

生产机房通常网络隔离得严，服务器没法直接yum装包。我的办法是在一台能上外网的测试机上提前下载好rpm包或二进制文件，用U盘、或者内网文件服务器把这几个文件带进去。

Debian系可以直接下载.deb包，CentOS/RHEL系可以下载.rpm包，然后：

rpm -ivh nmon-xxx.rpm

或者解压二进制包直接放到/usr/local/bin。

如果整个过程都不方便装包，那还有一条路：直接用其他系统自带命令代替。但请注意，top看CPU和内存没问题，iostat看磁盘没问题，sar看历史趋势需要配置sar服务，这些工具七拼八凑也能做基础监控，只是效率和直观程度完全比不上nmon。所以我在务实条件下，还是倾向于想办法把nmon塞进去，哪怕就一个二进制文件。

7.2 服务器时间不准，录出来的数据等于白录

这是我在帮人分析数据时踩过的最大的坑。nmon录制文件里的时间戳取自系统时钟，如果你的服务器时间没有同步，记录的时间会和真实时间偏差很大。我曾经收到一份客户发来的nmon数据，上面显示"凌晨3点"磁盘IO爆满，客户非说是晚上8点的故障现场。一查，服务器时区配置错误，差了5个小时，所有时间线都得手动偏移。

所以启动录制任务之前，务必先检查系统时间：

date

如果时间明显不对，先配置NTP或chrony同步再录制。对于长时间录制，哪怕中间有一次系统时间跳变，也会直接在图表时间轴上产生一个"断层"，分析时会非常别扭。

7.3 nmon常驻不退出，是不是该结束掉它

如果直接用nmon -f -s 5 -c 120这种方式，任务执行完会自动退出，不会常驻。但如果你用nmon不带参数启动，它会一直占据终端。有些新手在后台执行时忘记加-c参数，结果nmon会无限采样，文件越来越大，最终把磁盘塞满。

一个很实用的检查习惯是：

ps -ef | grep nmon

看到有大量nmon进程，先确认它们的分组参数。如果只是记录任务，你可以通过杀掉对应的PID结束，不会影响系统其他事务。但要特别留意：如果有人用nohup nmon &方式无限录制，文件的增长必须定期关注。

7.4 为什么记录出来的文件用analyser打开报错

报错原因里，有一大半和nmon版本有关。nmon在Linux和AIX上的文件格式有差异，如果你用的是AIX系统上采集的.nmon文件，却用Linux版analyser分析，就会报错或者生成不完整的内容。另外，某些nmon版本新加了字段，老版本的analyser不认识，也会报"Unknown section"之类的提示。

解决办法也简单：升级nmon和analyser到相互兼容的版本，或者把错误日志截图到社区里搜一下同类问题，通常都能找到匹配版本组合。还有一个小技巧：用文本编辑器打开.nmon文件，检查头部是否包含AAA这样的节标记，确认文件本身没有损坏。

7.5 在容器里使用nmon的注意事项

现在很多服务都跑在容器里，直接在容器内执行nmon，你会看到它只能采集容器所在宿主机的一部分指标。因为容器共享宿主机的内核，nmon读到的CPU、内存指标是整个宿主机的，而不是容器cgroup限制内的。若想监控容器自身的资源用量，应该看容器运行时提供的docker stats或crictl stats，而不是用nmon。

不过换个角度，nmon在宿主机上采集的数据对容器场景仍然有价值。比如宿主机CPU被打满，你想确认是不是某个容器在疯狂消耗CPU，可以用nmon从宿主机层面看到这个现象，再通过docker stats定位到具体容器。两个工具结合使用，效果更好。

8. 我把nmon用在哪里：几个典型场景复盘

8.1 线上服务卡顿，如何用nmon锁定嫌疑

我之前处理过一个线上服务变慢的问题。业务方说用户操作响应时间从200毫秒涨到了2秒，但查看监控面板，CPU和内存都正常。当时我在服务器上启动nmon，观察磁盘和网络页面，发现某块数据盘的Busy%一直徘徊在90%左右，而读写速率并不高。这基本可以断定磁盘IO队列已经堆积，物理磁盘面临性能瓶颈。

接着按t打开进程列表，输出IO比较密集的几个进程。再配合sar -d确认历史趋势，最后定位到是日志轮转脚本在压缩大文件，导致磁盘写入能力被榨干。把日志压制定时任务避开业务高峰后，问题就消失了。整个过程从怀疑到定位不到半小时，如果没有nmon同时展示磁盘和进程的关联数据，很难快速锁定一个"看起来都正常"的隐性瓶颈。

8.2 压测报告如何产出可复现的图表

我在做性能压测时，通常会把压测工具和nmon采集一起启动。比如用JMeter做接口压测的同时，在压力机（或被测服务器）上运行：

nmon -f -s 5 -c 180 -m /tmp/nmon_data

压测结束后，直接拿.nmon文件导入analyser，生成CPU、内存、磁盘、网络、进程趋势图，然后嵌到压测报告里。审阅报告的人不需要懂命令行，看几张图就能明白性能瓶颈在哪。这在交付给客户或上级的报告中帮助非常大，因为图表的说服力远大于"我们测了没啥问题"这样的结论。

另外，压测期间我会同时录制被测服务器和压力机两份数据。如果客户反馈"服务端响应慢"，我可以从压力机的nmon数据确认客户端侧是否出现CPU瓶颈、带宽打满等情况，从而区分是服务器瓶颈还是压测端瓶颈。这个细节很多人会忽略，但直接影响结论的准确性。

8.3 新服务器上线前用nmon验证基础性能

每台新服务器上架，我都会在安装完基础软件后跑一轮nmon数据采集，看看系统在空闲状态下的"底噪"水平：CPU是否有异常占用、内存是否被某些服务蚕食、磁盘是否出现异常IO等待、网络是否持续有流量。这就像家里水管装好后先通一通水，确认没有渗漏再住人。

具体做法是后台录制10到15分钟，然后分析图表。如果一台刚装好的系统在空闲状态下CPU持续有10%以上的使用率，或者磁盘存在持续写入，那就需要排查是否有异常进程或挖矿病毒残留。这个习惯帮我多次在上线前就发现了被植入的异常进程，避免带着问题上生产。

9. 总结一下我自己用nmon的体会

工具用得越久，越能感受到nmon在"轻量排障"这个维度上无可替代的价值。它不像Prometheus那样需要一整套部署、配置和运维成本，也不像sar、top那样单个指标割裂开来难以形成全局视图。nmon就是那把"拳头大小的瑞士军刀"，放在每一台服务器的工具箱里，需要的时候拿起来就能用，用完就放回去。

最后分享两个非常实用的小习惯。第一，我会把nmon二进制放入自建的内网软件源或者对象存储备份，这样以后无论遇到多新的服务器、多大的离线环境，都能用最快速度把工具铺开。第二，采集完数据后，我还习惯顺手把.nmon文件复制一份到巡检记录目录，和当天的变更记录放在一起，形成完整排障档案。

nmon本身不复杂，真正的难点在于你愿不愿意花时间把各种指标和业务场景对应起来。你越熟悉这些指标的含义，在关键时刻就越镇定，因为你手里有数据，心里有判断。希望这篇内容能帮你把nmon真正用起来，在下次系统闹脾气的时候，快速找到它的"痛点"。