4. 高级性能剖析工具：perf、ftrace、eBPF/BCC、SystemTap的原理与基本用法

在生产环境中定位内核级性能瓶颈，仅靠 top、vmstat 等传统工具往往力不从心。本章深入剖析四款业界主流的高级动态追踪与性能剖析工具——perf、ftrace、eBPF/BCC 和 SystemTap，从原理层理解其工作机制，并通过实战命令掌握其基本用法。

4.1 工具全景对比与选型

下表从内核版本依赖、安全模型、脚本能力和典型场景四个维度进行横向对比，帮助你在不同场景下快速选型。

4.2 perf：基于 PMU 的硬件性能计数器

perf 是 Linux 内核官方提供的性能剖析工具，核心依赖 PMU（Performance Monitoring Unit） 硬件计数器。它支持两种工作模式：计数模式（统计事件总数）和采样模式（按周期记录现场）。

4.2.1 核心原理

perf 通过 perf_event_open 系统调用与内核交互。内核将 PMU 计数器绑定到指定 CPU 或进程，当计数器溢出时触发 NMI（非屏蔽中断），在中断处理函数中记录 IP（指令指针）、调用栈等信息。

4.2.2 基本用法

以下命令覆盖了 perf 最常用的三个子命令：stat（计数）、record（采样）和 report（报告）。

# 1. 统计指定进程的 CPU 时钟和上下文切换次数（计数模式）
perf stat -e cycles,context-switches -p 1234 -- sleep 5

# 2. 全系统采样，以 99Hz 频率记录 CPU 热点（采样模式）
perf record -F 99 -a -g -- sleep 10

# 3. 查看采样报告，按 CPU 开销排序
perf report -n --sort comm,dso,symbol

# 4. 实时查看当前 CPU 上的热点函数（top 模式）
perf top -F 99 -p $(pgrep -x mysqld)

4.3 ftrace：内核内置的追踪框架

ftrace 是内核自带的追踪基础设施，通过 /sys/kernel/tracing/（或 /sys/kernel/debug/tracing/）伪文件系统暴露控制接口。它基于 静态插桩（函数入口/出口）和 动态插桩（kprobe）实现，开销极低。

4.3.1 核心原理

ftrace 的核心是 ring buffer（环形缓冲区）。当追踪被激活时，内核在函数入口处插入 mcount（或 fentry）指令，将函数调用信息写入 ring buffer。用户通过读取 trace 文件获取数据。

4.3.2 基本用法

ftrace 操作分为三步：选择追踪器、设置过滤、读取结果。以下演示追踪 do_sys_open 函数的调用。

# 1. 挂载 tracefs（如未自动挂载）
mount -t tracefs tracefs /sys/kernel/tracing/
cd /sys/kernel/tracing/

# 2. 查看可用的追踪器
cat available_tracers
# 输出示例：function function_graph wakeup_dl wakeup_rt wakeup irqsoff preemptoff preemptirqsoff nop

# 3. 激活 function_graph 追踪器
echo function_graph > current_tracer

# 4. 设置只追踪 do_sys_open 函数
echo do_sys_open > set_ftrace_filter

# 5. 开始追踪（清空旧数据）
echo 0 > tracing_on
echo 1 > tracing_on
# 执行目标操作（如 ls /tmp）
ls /tmp
# 停止追踪
echo 0 > tracing_on

# 6. 读取追踪结果
cat trace | head -20

4.4 eBPF/BCC：安全高效的动态追踪

eBPF（extended Berkeley Packet Filter）是一项革命性的内核技术，允许用户在沙箱中运行经过验证的字节码。BCC（BPF Compiler Collection）是 eBPF 的前端框架，提供 Python 接口和预编译工具集。

4.4.1 核心原理

eBPF 程序通过 bpf() 系统调用加载到内核。加载过程经过验证器（verifier）检查循环、指针安全等，确保不会导致内核崩溃。通过 JIT（Just-In-Time） 编译为本地机器码执行。eBPF 程序可以挂载到 kprobe、tracepoint、perf_event 等探针点。

4.4.2 基本用法

BCC 提供了大量现成的工具（位于 /usr/share/bcc/tools/），同时也支持编写自定义 Python 脚本。

# 1. 使用现成工具：追踪块设备 I/O 延迟分布
biosnoop -d 10

# 2. 追踪新创建的进程（execve 系统调用）
execsnoop

# 3. 分析 CPU 调度延迟（run queue latency）
runqlat

# 4. 自定义 eBPF 脚本：统计 open 系统调用的进程
cat << 'EOF' > trace_open.py
#!/usr/bin/python3
from bcc import BPF

bpf_text = """
#include <uapi/linux/ptrace.h>
int trace_sys_open(struct pt_regs *ctx) {
    char comm[TASK_COMM_LEN];
    bpf_get_current_comm(&comm, sizeof(comm));
    bpf_trace_printk("open called by %s\\n", comm);
    return 0;
}
"""
b = BPF(text=bpf_text)
b.attach_kprobe(event="do_sys_open", fn_name="trace_sys_open")
b.trace_print()
EOF
python3 trace_open.py

4.5 SystemTap：脚本化的内核探测

SystemTap 提供类 C 的脚本语言，通过 kprobe 和 uprobe 机制动态插入探针。它需要内核 debuginfo 包来解析符号和类型信息，适合编写复杂的条件式监控脚本。

4.5.1 核心原理

SystemTap 脚本（.stp）经过 stap 编译器转换为 C 代码，再编译为内核模块。模块加载后，探针函数在内核事件触发时执行，结果通过 printf 或聚合函数输出。

4.5.2 基本用法

以下脚本监控 do_sys_open 的调用频率和进程名，每 5 秒输出一次聚合结果。

# 1. 安装依赖（以 CentOS/RHEL 为例）
yum install systemtap systemtap-runtime kernel-debuginfo-$(uname -r)

# 2. 编写监控脚本 open_monitor.stp
cat << 'EOF' > open_monitor.stp
global open_counts

probe kernel.function("do_sys_open") {
    open_counts[execname()] <<< 1
}

probe timer.s(5) {
    printf("=== Open syscall count (last 5s) ===\n")
    foreach (name in open_counts- limit 10) {
        printf("%-20s : %d\n", name, @count(open_counts[name]))
    }
    delete open_counts
}
EOF

# 3. 运行脚本（需要 root 权限）
stap open_monitor.stp

4.6 四款工具协同使用策略

在实际性能优化工作中，四款工具并非互斥，而是形成互补的分层诊断体系：

1. 第一层（快速定位）：使用 perf top 或 perf record 识别 CPU 热点函数和进程。
2. 第二层（调用链分析）：使用 ftrace function_graph 追踪热点函数的调用路径和耗时分布。
3. 第三层（自定义追踪）：使用 eBPF/BCC 编写轻量探针，采集特定事件（如 TCP 重传、文件系统延迟）。
4. 第四层（复杂条件监控）：使用 SystemTap 处理需要复杂逻辑或长时间聚合的场景。