nmon有两种模式：交互式需按c/m/d/t等键手动开启对应指标并注意刷新，后台采集需正确设置-s和-c参数避免时间偏差，.nmon文件可直接文本查看但分析需注意工具兼容性与指标含义。
nmon 不是“装了就能用”的工具，它有两种截然不同的使用模式：交互式实时查看和后台批量采集，选错模式会导致数据拿不到、分析做不了、问题还更难定位。
交互模式下按什么键才能看到真实指标
直接运行 nmon 进入的是交互界面，但默认不显示任何数据——必须手动触发维度开关。常见误操作是只按一次 c 就以为在“监控CPU”，其实它只是切换显示/隐藏，且不自动刷新标题栏说明。
-
c显示 CPU 总体利用率（us/sy/wa/id），再按一次c会切到每个逻辑核的详细分布（需注意 Pi0 等 ARM 小核平台可能只显示单核） -
m显示内存时，重点关注Free和Active行，Swap在无 swap 分区的嵌入式设备上恒为 0，别被误导 -
d显示磁盘 I/O，但默认只列sda等主设备；若用 NVMe 或 LVM，需配合k（内核统计）或j（文件系统）交叉验证实际挂载点压力 -
t显示高耗进程，但仅展示采样瞬间的快照；如果某个进程 CPU 占用忽高忽低，单次t很可能错过峰值 - 所有视图中按
h可唤出快捷键列表，但部分版本（如 CentOS 7 自带旧版）不支持v（详细模式）或V（虚拟内存），需确认二进制版本是否 ≥16g
后台采集命令里 -s 和 -c 的真实约束关系
nmon -f -s 5 -c 720 看似简单，实际执行时间 = (c-1) × s 秒，不是 c × s。这意味着 720 次采样、间隔 5 秒，真正运行时长是 3595 秒（约 59.9 分钟），最后一次采样发生在第 3595 秒末。
- 若要覆盖整点开始的 60 分钟压测，应设为
-c 721，否则最后 5 秒数据缺失 -
-s最小值受内核定时器精度限制，Linux 一般不低于 1 秒；设-s 0.5会被自动修正为 1，且可能引发nanosleep: Invalid argument错误 -
-f生成的文件名含主机名+日期+时间，但若系统时间未同步（如 Pi0 出厂未配 NTP），文件名中的时间可能与实际采集时间偏差数小时，影响日志对齐 - 生产环境慎用
-t（记录高耗进程），它会额外 fork 子进程扫描/proc，在低配设备上可能引入毫秒级延迟抖动
nmon 文件必须用 nmon_analyser 才能看懂吗
不是。.nmon 文件本质是带时间戳的 CSV 文本，可用 head 或 grep 快速提取关键行，比如查某时刻 CPU 是否过载：
grep "CPU_ALL" yums_141111_1044.nmon | head -n 5
但真正容易踩坑的是解析工具本身：
-
nmon_analyser是 Excel 宏文件（.xlsm），Windows 10/11 默认禁用宏，需手动开启“信任中心→启用所有宏”，否则点击“Analyse nmon data”无响应 - Mac 上无法运行该宏，必须用
NmonSetup或 Python 脚本（如nmonparser）转成 CSV 后用 LibreOffice 打开 - Excel 中各 sheet 标签含义有歧义：
CPU_SUMM是每个 CPU 核的单独曲线，CPU_ALL才是整体平均值；很多人误把前者当总负载，导致误判扩容需求 - DISKXFER 和 DISKBSIZE 单位不同（前者是 IOPS，后者是 KB/IO），直接对比数值会得出“磁盘写放大”的错误结论
最常被忽略的一点：nmon 采集的数据是“瞬时快照”，没有上下文关联。比如 CPU_ALL 高的同时 DISK_BUSY 也高，不能直接断定是 IO 等待导致——必须用 vmstat 1 对比 wa 列确认。工具再好，也只是把原始信号摆出来，因果链得靠人来串。
