全量压测时监控Linux系统综合性能，关键在于分层抓重点、时间对齐、避免干扰：CPU用mpstat -P ALL 1查%iowait，内存用vmstat 1看so与cs，磁盘用iostat -x 1盯await和%util，进程用pidstat -u -r -d 1分离采集，nmon需后台模式运行且禁用交互视图。
全量压测时监控 Linux 系统综合性能，关键不是堆工具，而是分层抓重点、时间对齐、避免干扰。压测本身就会放大噪声，监控若配置不当，反而掩盖真实瓶颈。
核心监控维度与对应命令
不建议只盯一个指标，要同步覆盖 CPU、内存、磁盘 I/O、进程行为四层：
-
CPU 层：用
mpstat -P ALL 1每秒采集所有核的详细占比（%usr/%sys/%iowait/%idle），比 top 更稳定、无交互抖动；重点关注 %iowait 是否持续 >15%，这比 %us 高更危险 -
内存层：用
vmstat 1观察free（空闲）、si/so（swap 进出）、cs（上下文切换）；若 so > 0 或 cs > 50000/秒，说明内存已成瓶颈 -
磁盘 I/O 层：用
iostat -x 1看r/s、w/s、await和%util；SSD 的 await 超过 10ms、HDD 超过 30ms 就需警惕；%util 接近 100% 但 await 不高，可能是队列深度打满而非真慢 -
进程层：压测中禁用
top -t或 nmon 的t视图（会 fork 扫描 /proc，引入毫秒级抖动）；改用pidstat -u -r -d 1分离采集 CPU、内存、IO 使用，不干扰主线程
nmon 是压测期间最实用的综合采集工具
nmon 不是“开着就行”，必须用后台模式 + 合理参数，否则数据断档或失真：
- 命令示例：
nmon -f -s 2 -c 1800 -m /tmp/nmon_logs表示每 2 秒采一次、共 1800 次（覆盖 60 分钟），-m 指定日志目录防写满根分区 - 注意：
-c 1800实际运行时长是(1800−1)×2 = 3598 秒，想精确覆盖整点压测，应设-c 1801 - 生成的
.nmon文件可直接用 Excel 或 nmon_analyzer 分析；别用交互模式（按 c/m/d/t），压测中切视图会抢 CPU 资源 - 生产环境慎加
-t参数（记录高耗进程），低配设备上可能让压测结果偏高 3–5%
避免监控反成性能干扰的实操细节
很多团队压测不准，问题出在监控本身：
- 禁用
htop或带颜色/鼠标支持的终端监控——它们依赖 ncurses 渲染，压测高峰时可能触发 TTY 缓冲区争抢 - 不要在压测机本机跑 Grafana + Prometheus + node_exporter；采集 agent 应部署在独立节点，否则 exporter 自身就吃 CPU
- 关闭非必要日志轮转（如 logrotate）和定时任务（crond），防止压测中途触发磁盘写入毛刺
- 确认系统时间已同步（
timedatectl status），否则 nmon 文件名时间戳与实际不符，多机日志对齐失败
压测后快速定位瓶颈的判断链
拿到数据后，按顺序查三组关系，能快速收敛问题域：
- 如果
mpstat %iowait 高且iostat await 高→ 存储层瓶颈，查磁盘型号、RAID 级别、I/O 调度器（cfq/deadline） - 如果
vmstat r 值 > CPU 核数 × 2且%idle 接近 0→ CPU 密集型瓶颈，用perf top -g看热点函数 - 如果
free available 快速下降且vmstat so > 0→ 内存不足，检查是否有进程泄漏（pmap -x PID）、JVM 堆配置是否过大
