📚 课程目录第2章 RHEL性能观测工具链概览

2. RHEL性能观测工具链概览

在RHEL上做性能分析，第一步不是急着敲命令，而是先弄清楚“手上到底有哪些工具、它们各自看什么、什么时候该用谁”。RHEL的性能观测工具并不是零散堆在一起的，它们大致可以按数据来源和观测层次分成几类：一类是读取内核维护的计数器（如 /proc、/sys），一类是采集系统调用与调度事件，一类是直接挂到内核或用户态函数上做动态追踪，还有一类是抓取内核内部事件流做离线分析。理解这条“从静态计数到动态追踪”的谱系，才能在实际排障时快速选对工具。

按数据来源划分的工具家族

sysstat 是最常用的系统级统计工具集，核心成员包括 sar、iostat、mpstat、pidstat、sadf 等。它依赖 sysstat 服务周期性采样，把 CPU、内存、磁盘、网络、进程等指标写入 /var/log/sa/ 下的二进制文件，因此既能看实时数据，也能回看历史趋势。安装方式为 dnf install sysstat，启用采集用 systemctl enable --now sysstat。典型场景是“事后复盘”——比如用户反馈昨天下午系统卡顿，就可以用 sar -f /var/log/sa/sa15 -s 14:00:00 -e 16:00:00 回放那段时间的负载。

procps-ng 提供的是最贴近 /proc 的即时视图，代表命令有 ps、top、vmstat、free、slabtop、watch 等。它不依赖后台服务，随取随用，适合快速判断“现在谁在吃CPU、内存还剩多少、上下文切换是否异常”。例如 vmstat 1 5 每秒输出一行，重点看 r（运行队列长度）、b（阻塞进程数）、si/so（换页）、cs（上下文切换）这几列，能在一分钟内对系统整体压力形成判断。

util-linux 常被忽略，但它提供了不少底层观测与诊断命令，如 lsblk、lscpu、lsblk -o、findmnt、dmesg、flock、ionice、taskset、chrt 等。它更多用于“看清硬件与内核暴露的结构”，比如用 lscpu 确认 CPU 拓扑与 NUMA 节点，用 lsblk -t 查看块设备拓扑，为后续性能分析提供准确的硬件上下文。

perf 是内核自带的性能事件采样工具，基于 PMU（性能监控单元）和软件事件，能做 perf stat、perf record/report、perf top、perf trace 等。它既能统计 IPC、缓存命中率、分支预测失败等硬件指标，也能采样调用栈定位热点函数。安装用 dnf install perf。典型用法是 perf top -g 实时看热点，或 perf record -F 99 -a -g -- sleep 30 采样30秒后 perf report 分析。

bpftrace 和 trace-cmd 属于动态追踪与事件追踪层。bpftrace 用简洁的脚本语言把 eBPF 程序挂到内核探针（kprobe）、用户态探针（uprobe）、tracepoint 上，适合做“按条件统计、按进程过滤、按延迟分布”的精细观测，例如统计某进程的 read 延迟分布。trace-cmd 则是 ftrace 的前端，擅长抓取内核事件流并保存为 trace.dat，再用 trace-cmd report 或 KernelShark 做时间线分析，适合分析调度延迟、中断、块层事件之间的时序关系。

工具选择与安装要点

这些工具并非都要装。RHEL 最小化安装通常只带 procps-ng 和 util-linux；sysstat、perf、bpftrace、trace-cmd 需要额外安装。安装前建议先确认内核版本与仓库可用性：uname -r、dnf repolist。bpftrace 依赖 BTF 和内核 eBPF 支持，RHEL 8/9 默认内核已具备；trace-cmd 需要 tracefs 挂载，通常 /sys/kernel/tracing 已就绪。

选择工具时可按“先粗后细、先易后难”的原则：先用 top/vmstat 判断资源大类，再用 sar 看历史趋势，用 iostat/pidstat 定位到具体设备和进程，最后用 perf 或 bpftrace 深入函数与事件级别。下面这张图把这条工具链按“观测层次—数据来源—典型工具—适用场景”组织起来，便于在实际排障时快速对照选择。

安装与验证示例

下面给出一次典型的工具安装与验证过程，示例环境为 RHEL 9，内核 5.14。先确认仓库与内核，再按需安装：

# 确认系统与内核
uname -r
cat /etc/redhat-release

# 安装常用观测工具
dnf install -y sysstat procps-ng util-linux perf bpftrace trace-cmd

# 启用 sysstat 历史采集
systemctl enable --now sysstat
systemctl status sysstat --no-pager

# 验证各工具可用性
sar -V
vmstat 1 2
perf stat -e cycles,instructions -- sleep 1
bpftrace -l 'tracepoint:syscalls:sys_enter_*' | head -5
trace-cmd list | head -5

验证时重点看三点：sar -V 是否输出版本；vmstat 1 2 是否连续输出两行；perf stat 是否能读到 cycles 和 instructions。如果 perf stat 报 Permission denied，通常是 perf_event_paranoid 限制，可临时用 sysctl kernel.perf_event_paranoid=1 调整；如果 bpftrace 报 BTF 缺失，需确认内核是否带 CONFIG_DEBUG_INFO_BTF。

实际排障时不必把所有工具都跑一遍。建议按“vmstat/top 看整体 → sar 看历史 → iostat/pidstat 定位设备与进程 → perf/bpftrace 深入函数与事件”的顺序推进，每一步都记录关键指标和时间点，避免在无关方向上反复切换工具。

工具链的协同关系

这些工具不是互相替代，而是互补。sysstat 提供的是“面”，适合看趋势和容量；procps-ng 提供的是“点”，适合快速确认当前状态；util-linux 提供的是“底”，帮助确认硬件与内核结构；perf 提供的是“深”，能下钻到函数和硬件事件；bpftrace 与 trace-cmd 提供的是“细”，能按条件过滤、按延迟分布统计、按时间线还原事件顺序。真正高效的性能分析，往往是在这几层之间来回切换：先用面定位到异常时间段，再用点确认异常进程，再用深和细找到根因。

最后提醒一点：工具的输出必须结合业务上下文解读。例如 vmstat 中 r 列持续大于 CPU 核数，说明有排队；但如果是短时突发，未必是问题。再如 iostat -x 1 中 %util 接近 100%，对机械盘通常意味着饱和，对 NVMe 则未必。理解每个指标的物理含义和适用边界，比记住命令本身更重要。