3、性能观测工具入门：掌握top、htop、vmstat、iostat、sar、mpstat、pidstat等基础工具的使用方法，学会查看系统整体性能状态

性能优化的第一步不是盲目调参，而是建立“可观测性”。Linux 系统自带了一系列性能观测工具，它们看似简单，却构成了性能分析的基石。本章将系统讲解 top、htop、vmstat、iostat、sar、mpstat、pidstat 这七款核心工具，帮助你从 CPU、内存、磁盘 I/O、系统负载等维度建立全局性能视图。这些工具的共同特点是：轻量、无侵入、随系统发行，适合作为任何性能问题的第一排查入口。理解它们输出的指标含义与关联关系，是后续深入使用 perf、bcc、火焰图等高级工具的前提。

上图展示了七款工具在四个性能维度上的分布关系。在实际排查中，我们通常先使用 vmstat 1 或 top 获取系统整体状态，再根据瓶颈方向选择 mpstat（CPU 核间不均）、iostat（磁盘等待）、pidstat（定位具体进程）进行下钻分析。下面逐一拆解各工具的核心原理与实战用法。

3.1 top 与 htop：实时进程视图与系统概览

核心原理

top 是 Linux 中最经典的性能观测命令，它每隔 3 秒（默认）刷新一次，展示系统负载、进程 CPU 占用、内存占用等关键信息。htop 是 top 的增强版，提供了彩色界面、树状进程视图、鼠标操作支持，并允许直接发送信号给进程。两者读取的数据源均为 /proc 伪文件系统，但 htop 在交互体验和可视化上更胜一筹。

关键指标解读

操作流程

1. 执行 top 后按 P 按 CPU 排序，按 M 按内存排序，按 1 展开每个 CPU 核的使用情况。
2. 按 c 显示完整命令行，按 H 切换线程视图（排查多线程应用时非常关键）。
3. 在 htop 中按 F6 选择排序字段，按 F5 切换树状视图，按 F9 直接发送 kill 信号。

实战场景：定位 CPU 飙高进程

某 Web 服务器出现响应变慢，执行 top 后看到 %us 高达 85%，但 load average 只有 2.3（8 核机器）。按 P 排序后发现 java 进程 PID 2345 占用 320% CPU（多线程）。进一步按 H 切换线程视图，发现线程 2345-456 占用最高。随后使用 jstack 2345 | grep -A 20 'nid=0x1c8' 定位到具体代码行，发现是某个循环未加退出条件导致的死循环。修复后 CPU 降至 15%。

3.2 vmstat：系统整体状态快照

核心原理

vmstat 是查看系统整体性能最简洁的工具，它同时报告进程、内存、分页、块 I/O、陷阱和 CPU 活动。推荐使用 vmstat 1 5 每秒采样一次，共采样 5 次，以观察趋势而非瞬时值。

关键字段解析

判断方法

• 如果 r 持续大于 CPU 核数，说明 CPU 资源不足。
• 如果 si/so 长期非零，说明物理内存不足，系统正在频繁换页。
• 如果 cs（上下文切换）超过 10 万次/秒，需关注线程数过多或锁竞争。
• 如果 wa 高且 bi/bo 大，说明磁盘 I/O 是瓶颈。

3.3 iostat：磁盘 I/O 性能分析

核心原理

iostat 用于监控系统输入/输出设备负载，核心数据来自内核块设备层。使用 iostat -x 1 可显示扩展统计信息，包括每秒 I/O 次数、吞吐量、平均 I/O 等待时间、队列长度等。

核心指标

案例拆解：数据库磁盘瓶颈定位

某 MySQL 实例出现慢查询，iostat -x 1 显示 sda 的 %util 达到 98%，await 为 45ms，而 svctm 仅 2ms。这说明大量 I/O 请求在队列中等待，磁盘本身服务能力尚可，但请求量过大。进一步使用 pidstat -d 1 定位到 mysqld 进程每秒产生 1200 次写请求。通过优化 SQL 减少全表扫描、将临时表从磁盘改为内存表，并将 innodb_flush_log_at_trx_commit 从 1 调整为 2（允许每秒刷盘），%util 降至 45%，await 降至 8ms。

3.4 sar：历史性能数据回溯

核心原理

sar（System Activity Reporter）是 sysstat 包的核心工具，它不仅能实时监控，更重要的是可以记录历史数据，用于事后分析。系统通过 cron 定时执行 sa1 采集数据，sa2 生成日报，数据默认保存在 /var/log/sa/ 目录。

常用命令组合

sar -u 1 3          # 查看 CPU 使用率，每秒一次共 3 次
sar -r 1 3          # 查看内存使用情况
sar -b 1 3          # 查看磁盘 I/O 吞吐
sar -n DEV 1 3      # 查看网络接口流量
sar -q 1 3          # 查看系统负载和运行队列
sar -f /var/log/sa/sa$(date +%d)  # 查看今天的历史数据

实战场景：排查夜间性能问题

某应用每天凌晨 2 点出现响应超时，但白天正常。由于问题发生在非工作时间，无法实时观察。通过 sar -f /var/log/sa/sa15 -q 查看 15 号的历史负载，发现凌晨 2:00-2:30 的 runq-sz（运行队列长度）从 2 飙升至 18，同时 sar -b 显示 bwrtn/s（每秒写入块数）从 500 升至 8000。结合业务日志确认是定时备份任务与数据统计任务重叠执行。解决方案是将备份任务提前至 1:30，并限制其 I/O 优先级（ionice -c 3），问题解决。

3.5 mpstat 与 pidstat：多核与进程级下钻

mpstat：多核 CPU 利用率分析

mpstat -P ALL 1 可以查看每个 CPU 核的独立使用率。当系统整体 CPU 不高但性能差时，mpstat 能揭示“核间不均”问题——例如 8 核系统中 1 个核 100% 而其他核空闲，这通常由单线程应用或锁竞争导致。

pidstat：进程级性能监控

pidstat 是 sysstat 家族中用于按进程维度统计的工具，常用参数包括：

pidstat -u 1        # 查看所有进程 CPU 使用率
pidstat -r 1        # 查看进程内存使用
pidstat -d 1        # 查看进程磁盘 I/O
pidstat -w 1        # 查看进程上下文切换
pidstat -p 1234 -t 1 # 查看指定进程的线程统计

案例：多核不均问题定位

某 Nginx 网关出现延迟抖动，top 显示整体 CPU 仅 30%，但 mpstat -P ALL 1 发现 CPU3 使用率 100%，其他核低于 20%。使用 pidstat -u 1 | grep -E 'PID|nginx' 定位到 worker 进程 PID 5678 占满 CPU3。进一步使用 pidstat -w -p 5678 1 发现该进程每秒非自愿上下文切换高达 5000 次，说明存在锁竞争。通过调整 Nginx 的 worker_processes 为 auto 并开启 accept_mutex off，将请求分散到多核，CPU3 使用率降至 40%，延迟恢复稳定。

3.6 工具协同：从全局到局部的排查路径

标准排查流程

1. 第一步：全局扫描——执行 vmstat 1 5 和 top，判断瓶颈在 CPU、内存还是 I/O。
2. 第二步：维度确认——若 CPU 高，用 mpstat -P ALL 1 确认是否多核均衡；若 I/O 高，用 iostat -x 1 确认设备与等待时间。
3. 第三步：进程定位——使用 pidstat -u 1 或 pidstat -d 1 找到具体进程。
4. 第四步：线程深挖——对可疑进程使用 pidstat -t -p PID 1 或 top 的 H 模式定位线程。
5. 第五步：历史回溯——若问题间歇性发生，使用 sar -f 查看历史数据确认规律。

工具选择对比表

3.7 常见误区与总结复盘

总结复盘

本章的七款工具构成了 Linux 性能观测的第一层能力。核心方法论是：先全局后局部，先指标后数据，先趋势后定位。vmstat 和 top 负责“看全局”，mpstat 和 iostat 负责“定维度”，pidstat 负责“找进程”，sar 负责“查历史”。在实际工作中，建议将这些工具组合成固定的排查脚本，例如：

# 性能快照脚本
echo "===== 系统负载 ====="; uptime
echo "===== 整体状态 ====="; vmstat 1 3
echo "===== CPU 多核 ====="; mpstat -P ALL 1 2
echo "===== 磁盘 I/O ====="; iostat -x 1 2
echo "===== 内存详情 ====="; sar -r 1 2
echo "===== 进程 TOP10 ====="; pidstat -u 1 2 | tail -12

掌握这些工具的输出含义与关联关系，是后续学习 perf 剖析、火焰图分析、内核追踪等高级技术的基础。下一层能力将涉及更细粒度的采样与追踪，但无论工具多高级，最终都要回归到“理解系统如何工作”这一根本。