1. 项目概述与工具定位1.1 为什么还需要一款老牌监控工具做过Linux运维的朋友应该都有这种感觉系统监控工具多得眼花缭乱从系统自带的top、vmstat、iostat到后来崛起的PrometheusGrafana组合再到各种Agent采集方案几乎每个团队都有自己的监控全家桶。但真要排查一台机器的临时性能问题或者是面对一台没装任何Agent的新服务器我却总是会第一时间打开nmon。nmon全称是Nigels 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屏幕上会实时刷新一台机器的整体状态。页面默认不显示任何图表你需要通过快捷键打开关心的指标区域常用的按键如下cCPU利用率显示每个核心的使用率、等待率、空闲率。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 从哪里获取nmonnmon的官方网站托管在SourceForge上项目名叫nmon for Linux页面里会根据CPU架构区分不同版本的二进制包。主流Linux发行版也会有各自的软件仓库集成比如Debian/Ubuntu系列apt install nmonRHEL/CentOS/Rocky/AlmaLinux系列yum install nmon或dnf install nmonSUSE/openSUSEzypper 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作为采集器集成进去统一管理多台服务器的采集任务。这种思路不是不行但要注意平台本身可能自带AgentAgent再去拉起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 1205秒一次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。步骤如下打开Excel或者WPS启用宏功能。第一次打开xlsm文件时如果被禁用宏需要在设置里允许启用。点击Excel菜单栏或页面上出现的Analyse nmon data按钮。选择你的.nmon文件确认导入。分析过程可能需要几十秒到数分钟取决于采样点数量。完成后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真正用起来在下次系统闹脾气的时候快速找到它的痛点。
1. 项目概述与工具定位1.1 为什么还需要一款老牌监控工具做过Linux运维的朋友应该都有这种感觉系统监控工具多得眼花缭乱从系统自带的top、vmstat、iostat到后来崛起的PrometheusGrafana组合再到各种Agent采集方案几乎每个团队都有自己的监控全家桶。但真要排查一台机器的临时性能问题或者是面对一台没装任何Agent的新服务器我却总是会第一时间打开nmon。nmon全称是Nigels 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屏幕上会实时刷新一台机器的整体状态。页面默认不显示任何图表你需要通过快捷键打开关心的指标区域常用的按键如下cCPU利用率显示每个核心的使用率、等待率、空闲率。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 从哪里获取nmonnmon的官方网站托管在SourceForge上项目名叫nmon for Linux页面里会根据CPU架构区分不同版本的二进制包。主流Linux发行版也会有各自的软件仓库集成比如Debian/Ubuntu系列apt install nmonRHEL/CentOS/Rocky/AlmaLinux系列yum install nmon或dnf install nmonSUSE/openSUSEzypper 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作为采集器集成进去统一管理多台服务器的采集任务。这种思路不是不行但要注意平台本身可能自带AgentAgent再去拉起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 1205秒一次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。步骤如下打开Excel或者WPS启用宏功能。第一次打开xlsm文件时如果被禁用宏需要在设置里允许启用。点击Excel菜单栏或页面上出现的Analyse nmon data按钮。选择你的.nmon文件确认导入。分析过程可能需要几十秒到数分钟取决于采样点数量。完成后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真正用起来在下次系统闹脾气的时候快速找到它的痛点。
