eBPF 深度实战：内核可观测性革命与性能分析的全栈指南

引言

在 Linux 系统的可观测性领域，eBPF（Extended Berkeley Packet Filter）是一场革命。它允许在不修改内核源码、不加载内核模块的前提下，在运行时的内核中安全地执行沙箱程序。这意味着：零成本 Instrumentation、纳秒级事件捕获、生产环境热加载——即使是承载着百万 QPS 的数据库集群，也能在线插入探针。

本文将从 eBPF 的执行模型出发，系统讲解 BPF 虚拟机架构、验证器（Verifier）安全机制、Map 数据结构体系、四类探针（tracepoint/kprobe/uprobe/XDP）的实战用法，最后深入 Berkeley 性能分析的生产级实践。

一、eBPF 架构总览

1.1 从 BPF 到 eBPF 的演化

时间线：
1992 — BSD Packet Filter (BPF): 仅用于网络包过滤，256 字节指令集
2014 — Linux 3.18: eBPF 首次合并主线（Alexei Starovoitov）
     - 扩展寄存器：10 个 64位寄存器 (R0-R9 + R10 frame pointer)
     - 新增 BPF Map：持久化键值存储
     - bpf() 系统调用统一入口
2015 — Linux 4.1: BPF JIT 编译器
2016 — Linux 4.7: XDP 与 TC 钩子
2017 — Linux 4.15: BTF (BPF Type Format)
2018 — Linux 5.0: BCC 成熟、bpftrace 发布
2020 — Linux 5.10: BPF CO-RE (Compile Once, Run Everywhere)
2022+ — Linux 6.x: 可休眠 BPF 程序、BPF tracing trampoline

1.2 执行模型：事件驱动的内核虚拟机

eBPF 程序的核心设计哲学是"事件驱动"——当特定内核钩子（hook point）触发时，BPF 程序被调度执行。整个过程无需上下文切换，无内存分配，平均延迟在 50-100 纳秒级别。

┌─────────────────────────────────────────────────────────────┐
│  用户态                                                       │
│  ┌──────────┐   bpf_load()    ┌──────────────────────┐      │
│  │ ELF .o   │ ──────────────► │ eBPF 验证器           │      │
│  │ Bytecode │                 │ (安全/终止检查)        │      │
│  └──────────┘                 └──────────┬───────────┘      │
│                                          │ 验证通过           │
│                                          ▼                   │
│                               ┌──────────────────────┐      │
│                               │ JIT 编译为原生指令     │      │
│                               │ (x86_64 / arm64)     │      │
│                               └──────────┬───────────┘      │
│                                          │                   │
├──────────────────────────────────────────┼────────────────── │
│  内核态                                   ▼                   │
│  ┌──────────┐     事件      ┌──────────────────────────┐   │
│  │ 探针钩子  │ ───────────► │ eBPF 程序 (受限 C / IR)   │   │
│  │(kprobe等) │             │ R1 = ctx 指针             │   │
│  └──────────┘              │ R2-R5 = 传入参数           │   │
│                            │ R0 = 返回值                │   │
│                            │ 仅 R10 = 只读栈帧           │   │
│                            └──────────┬───────────────┘   │
│                                       │                     │
│                                       ▼                     │
│                            ┌──────────────────────────┐   │
│                            │ BPF Map (共享数据存储)     │   │
│                            │ ↔ 用户态双向通信           │   │
│                            └──────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘

1.3 关键约束：为什么 eBPF "安全"

• 验证器（Verifier）：在加载时静态分析所有执行路径，确保：
  • 无无限循环（最大 4096 条指令限制）
  • 无越界内存访问
  • 无未初始化寄存器读取
  • 仅调用白名单 helper 函数
• 仅能访问有限内存：通过 bpf_probe_read() 间接读取内核指针，需在验证器允许范围内
• 不可休眠（传统 BPF 程序）：不使用 GFP_KERNEL 分配、不持有 mutex（5.10+ 可休眠程序除外）
• 无全局变量：状态必须存储在 BPF Map 中

二、BPF 虚拟机指令系统与寄存器规范

2.1 寄存器约定

2.2 指令编码

// eBPF 指令 = 8 字节 (64 bits)
struct bpf_insn {
    __u8  opcode;    // 操作码： CALL/JMP/STORE/LOAD/ALU/RET
    __u8  dst_reg:4; // 目标寄存器 R0-R9
    __u8  src_reg:4; // 源寄存器
    __s16 off;       // 有符号偏移
    __s32 imm;       // 有符号立即数
};

// 示例： BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 42)
// 含义: *(u64 *)(r10 - 8) = 42
// 将 42 写入栈帧偏移 -8 处（分配局部变量）

// 示例： BPF_ALU64_REG(BPF_ADD, BPF_REG_0, BPF_REG_1)
// 含义: r0 = r0 + r1
// 64位寄存器加法

2.3 调用约定：BPF 到 BPF 与 BPF 到 Helper

// BPF 函数调用规则：
// - r1-r5 传参（最多 5 个）
// - r0 返回
// - r6-r9 被调用者保存（callee-saved）
// - 栈帧仅限 r10 以下（每帧 512 字节）
// - 嵌套调用深度 ≤ 8（早期内核）/ 32（5.2+）

// Helper 调用（通过 opcode 0x85）
static long (*bpf_map_lookup_elem)(void *map, const void *key) = (void *) 1;
static long (*bpf_map_update_elem)(void *map, const void *key, const void *value, u64 flags) = (void *) 2;
static long (*bpf_perf_event_output)(void *ctx, void *map, u64 flags, void *data, u64 size) = (void *) 25;
static long (*bpf_get_current_comm)(char *buf, u32 size) = (void *) 16;
static long (*bpf_ktime_get_ns)(void) = (void *) 5;
static long (*bpf_trace_printk)(const char *fmt, u32 fmt_size, ...) = (void *) 6;
// 总共有 180+ 个 helper 函数（Linux 6.x）

三、BPF Map 数据结构体系

BPF Map 是 eBPF 程序与用户态通信的唯一通道，也是多个 BPF 程序之间共享状态的机制。Linux 内核提供了 30+ 种 Map 类型。

3.1 核心 Map 类型一览

3.2 Map 创建与生命周期

// 方式1: 通过 BCC/libbpf 在 ELF 中声明（推荐）
struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, 10240);
    __type(key, u32);
    __type(value, u64);
} exec_start SEC(".maps");

// 方式2: 通过 BPF syscall 直接创建
union bpf_attr attr = {
    .map_type    = BPF_MAP_TYPE_HASH,
    .key_size    = sizeof(u32),
    .value_size  = sizeof(u64),
    .max_entries = 1024,
};
int map_fd = syscall(__NR_bpf, BPF_MAP_CREATE, &attr, sizeof(attr));

// BPF_ANNOTATE_KV_PAIR(exec_start, u32, u64); // BCC 专用
// ops: bpf_map_lookup_elem / update_elem / delete_elem / get_next_key

3.3 CO-RE (Compile Once, Run Everywhere)

BPF CO-RE 解决了跨内核版本兼容性问题。通过 BTF（BPF Type Format）提供的类型信息，libbpf 在加载时自动重定位字段偏移，使得同一份 eBPF 二进制可在不同内核版本上运行。

// 常规写法（硬编码偏移，跨内核崩溃）：
// data = (u64)task->mm->arg_start;

// CO-RE 写法（通过 BTF 解析实际偏移）：
#include "vmlinux.h"                    // 由 bpftool gen skeleton 生成
#define BPF_CORE_READ(ptr, a) __builtin_preserve_access_index(    typeof(*((typeof(ptr))NULL)->a) __r; __builtin_memcpy(&__r, &(ptr)->a, sizeof(__r)); __r)

// 使用：
u64 arg_start = BPF_CORE_READ(task, mm, arg_start);

// 编译命令：
// clang -O2 -g -target bpf -c prog.c -o prog.o
// bpftool gen skeleton prog.o > prog.skel.h
// → 生成骨架文件，包含所有 Map/program 的 fd 绑定

四、四类探针的实战用法

4.1 Tracepoint：预定义事件（最低开销）

Tracepoint 是内核中预插的轻量级钩子（仅一条跳转指令开销）。通过 /sys/kernel/debug/tracing/events/ 查看所有可用事件。

// 跟踪 sched:sched_process_exec（进程执行）
SEC("tp/sched/sched_process_exec")
int tracepoint__sched__sched_process_exec(struct trace_event_raw_sched_process_exec *ctx)
{
    u32 pid = bpf_get_current_pid_tgid() >> 32;
    u32 tgid = bpf_get_current_pid_tgid();
    
    struct event e = {};
    e.pid = tgid;
    e.ts = bpf_ktime_get_ns();
    bpf_get_current_comm(&e.comm, sizeof(e.comm));
    
    // 从 ctx 提取文件名（通过 BTF 自动重定位）
    bpf_probe_read_str(&e.filename, sizeof(e.filename), ctx->filename);
    
    // 发送到 ring buffer
    bpf_ringbuf_output(&events, &e, sizeof(e), 0);
    return 0;
}

// 可用 tracepoint 分类：
// sched/*    — 调度器事件
// syscalls/* — syscall 入口/退出
// skb/*      — 网络 SKB 事件
// irq/*      — 中断
// kmem/*     — 内存分配
// filemap/* — 文件系统缓存
// 等等

4.2 Kprobe/Kretprobe：动态内核探针

Kprobe 允许在任意内核函数入口插桩（受限于黑名单），Kretprobe 在捕获返回值。开销略高于 tracepoint（触发中断 50-150ns）。

// 示例：跟踪 tcp_sendmsg 的调用频率和参数
SEC("kprobe/tcp_sendmsg")
int BPF_KPROBE(tcp_sendmsg_probe, struct sock *sk, struct msghdr *msg, size_t size)
{
    // BPF_KPROBE 宏自动从 pt_regs 提取参数（无需手动解引用）
    u16 dport = sk->__sk_common.skc_dport;
    u16 sport = sk->__sk_common.skc_num;
    
    struct net_ctx ctx = {};
    ctx.sport = sport;
    ctx.dport = ntohs(dport);
    ctx.bytes = size;
    ctx.pid = bpf_get_current_pid_tgid() >> 32;
    
    // 记录到直方图 Map
    u64 key = size / 1024; // KB 级别
    u64 *count = bpf_map_lookup_elem(&size_hist, &key);
    if (count) __sync_fetch_and_add(count, 1);
    else { u64 init = 1; bpf_map_update_elem(&size_hist, &key, &init, BPF_ANY); }
    
    return 0;
}

// 示例：跟踪 do_nanosleep 延迟分布
SEC("kretprobe/do_nanosleep")
int BPF_KRETPROBE(nanosleep_exit, long ret)
{
    // ret = 0 (正常) / EINTR/ETIMOUT (被中断或超时)
    u32 pid = bpf_get_current_pid_tgid() >> 32;
    
    // 与 kprobe 成对使用记录延迟
    u64 *start = bpf_map_lookup_elem(&start_times, &pid);
    if (start) {
        u64 delta = bpf_ktime_get_ns() - *start;
        u64 key = bpf_log2l(delta / 1000); // 微秒级 2 进制桶
        u64 *cnt = bpf_map_lookup_elem(&lat_hist, &key);
        if (cnt) __sync_fetch_and_add(cnt, 1);
        bpf_map_delete_elem(&start_times, &pid);
    }
    return 0;
}

4.3 Uprobe/Uretprobe：用户态函数追踪

Uprobe 在 ELF 二进制（可执行文件或共享库）的指定偏移插桩，无需修改目标程序。

// 跟踪 libc malloc 调用频率（按调用栈分组）
SEC("uprobe//usr/lib/x86_64-linux-gnu/libc.so.6:malloc")
int malloc_enter(struct pt_regs *ctx)
{
    u32 pid = bpf_get_current_pid_tgid() >> 32;
    u64 size = PT_REGS_PARM1(ctx); // 第一个参数 = size
    
    // 捕获调用栈
    u32 stack_id = bpf_get_stackid(ctx, &stack_traces, BPF_F_USER_STACK);
    
    struct alloc_key key = {};
    key.pid = pid;
    key.stack_id = stack_id;
    key.size = size;
    
    // 统计分配次数和总字节数
    struct alloc_val zero = {}, *val = bpf_map_lookup_elem(&allocs, &key);
    if (val) {
        __sync_fetch_and_add(&val->count, 1);
        __sync_fetch_and_add(&val->total_size, size);
    } else {
        zero.count = 1;
        zero.total_size = size;
        bpf_map_update_elem(&allocs, &key, &zero, BPF_ANY);
    }
    return 0;
}

// 使用方式：
// 1. 编译为 .o
// 2. 通过 BCC Python API：
//    b.attach_uprobe(name="c", sym="malloc", fn_name="malloc_enter")
//    b.attach_uretprobe(name="c", sym="free", fn_name="free_exit")

4.4 XDP：极速网络数据包处理

XDP (eXpress Data Path) 在网卡驱动层直接处理数据包，早于内核网络栈，可达到线速（100Gbps+）处理能力。

// 示例：简单的 SYN Flood 防护
struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, 65536);
    __type(key, __be32);   // 源 IP
    __type(value, u64);    // 最后 SYN 时间戳
} syn_cache SEC(".maps");

SEC("xdp")
int syn_filter(struct xdp_md *ctx)
{
    void *data_end = (void *)(long)ctx->data_end;
    void *data     = (void *)(long)ctx->data;
    
    struct ethhdr *eth = data;
    if ((void *)(eth + 1) > data_end) return XDP_DROP;
    if (eth->h_proto != htons(ETH_P_IP)) return XDP_PASS;
    
    struct iphdr *ip = (void *)(eth + 1);
    if ((void *)(ip + 1) > data_end) return XDP_DROP;
    if (ip->protocol != IPPROTO_TCP) return XDP_PASS;
    
    struct tcphdr *tcp = (void *)ip + (ip->ihl * 4);
    if ((void *)(tcp + 1) > data_end) return XDP_DROP;
    
    // 仅检查 SYN 包（无 ACK）
    if (!(tcp->syn && !tcp->ack)) return XDP_PASS;
    
    __be32 src_ip = ip->saddr;
    u64 now = bpf_ktime_get_ns();
    u64 *last = bpf_map_lookup_elem(&syn_cache, &src_ip);
    
    if (last) {
        // 1 秒内超过 100 次 SYN → DROP
        if (now - *last < 1000000000ULL) {
            // 计数此源的 SYN 频率
            return XDP_DROP;
        }
    }
    bpf_map_update_elem(&syn_cache, &src_ip, &now, BPF_ANY);
    return XDP_PASS;
}

// 加载：ip link set dev eth0 xdp obj syn_filter.o
// 卸载：ip link set dev eth0 xdp off

// 性能对比：
// iptables -A INPUT -p tcp --syn -m limit: ~500K pps（CPU 瓶颈在 netfilter）
// XDP_DROP:                        ~24M pps（线速，RX 队列直处理）

五、性能分析生产级实践

5.1 Off-CPU 分析：找到阻塞时间

Off-CPU 时间揭示了进程"不在 CPU 上等待"的真实原因（锁争用、I/O 等待、调度延迟）。仅靠 On-CPU profiling（如 perf top）会遗漏这些。

// eBPF Off-CPU 追踪核心逻辑
struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, 102400);
    __type(key, struct key_t);   // (pid, kernel_stack_id, user_stack_id)
    __type(value, u64);          // 累计阻塞时间 (ns)
} offcpu_time SEC(".maps");

SEC("tp/sched/sched_switch")
int trace_sched_switch(struct trace_event_raw_sched_switch *ctx)
{
    u32 prev_pid = ctx->prev_pid;
    u32 prev_state = ctx->prev_state;
    
    // 仅捕获 TASK_RUNNING → TASK_UNINTERRUPTIBLE 切换
    // 即：因为 I/O 等待主动放弃 CPU
    if (prev_state != TASK_RUNNING) return 0;
    
    u64 ts = bpf_ktime_get_ns();
    // 记录离开 CPU 的时间戳
    bpf_map_update_elem(&start, &prev_pid, &ts, BPF_ANY);
    return 0;
}

// 当该进程被重新调度时计算时间差
SEC("tp/sched/sched_switch")
int sched_switch_resume(struct trace_event_raw_sched_switch *ctx)
{
    u32 next_pid = ctx->next_pid;
    u64 *start_ts = bpf_map_lookup_elem(&start, &next_pid);
    if (!start_ts) return 0;
    
    u64 delta = bpf_ktime_get_ns() - *start_ts;
    
    struct key_t key = {};
    key.pid = next_pid;
    key.kern_stack = bpf_get_stackid(ctx, &stack_traces, 0);
    key.user_stack = bpf_get_stackid(ctx, &stack_traces, BPF_F_USER_STACK);
    
    // 累加到直方图
    u64 *total = bpf_map_lookup_elem(&offcpu_time, &key);
    if (total) __sync_fetch_and_add(total, delta);
    else { bpf_map_update_elem(&offcpu_time, &key, &delta, BPF_ANY); }
    
    bpf_map_delete_elem(&start, &next_pid);
    return 0;
}

// bpftrace 版本（单行搞定）：
// bpftrace -e 'tracepoint:sched:sched_switch /prev_state==0/ 
//              { @start[pid] = nsecs; }
//              sched:sched_switch /@start[pid]/ 
//              { @off_us = hist((nsecs - @start[pid]) / 1000); 
//                delete(@start[pid]); }'

5.2 系统调用延迟直方图

通过跟踪 syscall 入口和退出之间的延迟，可即时发现 I/O 延迟异常。

// 跟踪 read/write/pread64 的延迟分布
struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, 65535);
    __type(key, u64);     // pid_tgid
    __type(value, u64);   // 进入时间戳
} start SEC(".maps");

struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, 65535);
    __type(key, u64);     // 桶索引（log2）
    __type(value, u64);   // 计数
} hist SEC(".maps");

SEC("tp/raw_syscalls/sys_enter")
int sys_enter(struct trace_event_raw_sys_enter *ctx)
{
    if (ctx->id != __NR_read && ctx->id != __NR_write) return 0;
    u64 id = bpf_get_current_pid_tgid();
    u64 ts = bpf_ktime_get_ns();
    bpf_map_update_elem(&start, &id, &ts, BPF_ANY);
    return 0;
}

SEC("tp/raw_syscalls/sys_exit")
int sys_exit(struct trace_event_raw_sys_exit *ctx)
{
    if (ctx->id != __NR_read && ctx->id != __NR_write) return 0;
    u64 id = bpf_get_current_pid_tgid();
    u64 *tsp = bpf_map_lookup_elem(&start, &id);
    if (!tsp) return 0;
    
    u64 delta_us = (bpf_ktime_get_ns() - *tsp) / 1000;
    u64 key = bpf_log2l(delta_us);
    if (key >= 64) key = 63; // 上限桶
    
    u64 *count = bpf_map_lookup_elem(&hist, &key);
    if (count) __sync_fetch_and_add(count, 1);
    else { u64 one = 1; bpf_map_update_elem(&hist, &key, &one, BPF_ANY); }
    
    bpf_map_delete_elem(&start, &id);
    return 0;
}

// 输出直方图 (bpftrace 友好版):
// bpftrace -e 'tracepoint:syscalls:sys_enter_read 
//              { @start[tid] = nsecs; }
//              tracepoint:syscalls:sys_exit_read /@start[tid]/ 
//              { @ = hist((nsecs - @start[tid]) / 1000); 
//                delete(@start[tid]); }'
//
// 输出示例:
// @:
// [1]                ████████████████████████  12612
// [2]                ████████████              5834
// [4]                █████                     2345
// [8]                ██                        1023
// [16]               █                         456
// [32]               ▌                         89
// [64]               ▏                         12    ← P99 > 64us!

5.3 内存分配追踪与泄漏检测

// 使用 uprobe 跟踪 malloc/free（libc）时的调用栈
// 多次采样（而非全量跟踪，控制开销 <1%）

struct alloc_info {
    u64 size;
    u64 stack_id;
    u32 pid;
};

struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, 100000);
    __type(key, u64);      // 返回的指针 (malloc 返回值)
    __type(value, struct alloc_info);
} live_allocs SEC(".maps");

struct {
    __uint(type, BPF_MAP_TYPE_STACK_TRACE);
    __uint(max_entries, 10000);
    __uint(value_size, 16 * sizeof(u64));  // 深度 16
} stacks SEC(".maps");

SEC("uprobe/libc:malloc")
int malloc_enter(struct pt_regs *ctx)
{
    // 采样：仅跟踪 1/100 次调用
    if ((bpf_get_current_pid_tgid() % 100) != 0) return 0;
    
    u64 size = PT_REGS_PARM1(ctx);
    u64 ret_addr = PT_REGS_RC(ctx); // kretprobe 设置
    
    // 实际实现需配合 uretprobe 获取返回值
    // 简化版（真实使用 bpftrace 更高效）：
    u32 pid = bpf_get_current_pid_tgid() >> 32;
    bpf_map_update_elem(&size_by_pid, &pid, &size, BPF_ANY);
    return 0;
}

// bpftrace 内存泄漏检测（实战效果最佳）:
// bpftrace -e 'uprobe:/lib/x86_64-linux-gnu/libc.so.6:malloc 
//              { @[ustack] = count(); }
//              interval:s:5
//              { print(@, 20); clear(@); }'

5.4 调度器延迟分析

测量进程从"变为可运行"到"实际获得 CPU"之间的延迟，对延迟敏感型应用（高频交易、音视频处理）至关重要。

# 列出所有 tracepoint
bpftrace -l 'tracepoint:*'

# 列出所有内核函数（过滤含 tcp 的）
bpftrace -l 'kprobe:tcp_*'

# 单行统计 syscall 次数（按调用名分组）
bpftrace -e 'tracepoint:syscalls:sys_enter_* 
             { @[comm] = count(); }'

# 统计块 I/O 大小分布
bpftrace -e 'tracepoint:block:block_rq_issue 
             { @bytes = hist(args->bytes); }'

# 每秒输出 accept 次数（按进程）
bpftrace -e 'kprobe:sys_accept4 
             { @[comm] = count(); }
             interval:s:1 { print(@); clear(@); }'

# 追踪文件打开（按进程聚合）
bpftrace -e 'tracepoint:syscalls:sys_enter_openat 
             { @[comm, str(args->filename)] = count(); }'

# 输出延迟 > 10ms 的 read 调用
bpftrace -e 'tracepoint:syscalls:sys_enter_read 
             { @start[tid] = nsecs; }
             tracepoint:syscalls:sys_exit_read /@start[tid]/
             {$us=(nsecs-@start[tid])/1000; 
              if ($us > 10000) { printf("%s read %d bytes in %d μs\n", comm, args->ret, $us); }
              delete(@start[tid]);}'

#!/usr/bin/env python3
from bcc import BPF
import ctypes as ct

# 加载 eBPF 程序
prog = """
#include <uapi/linux/ptrace.h>
#include <linux/sched.h>

BPF_HISTOGRAM(dist, u64);

int do_trace(struct pt_regs *ctx) {
    u64 pid = bpf_get_current_pid_tgid() >> 32;
    
    // 仅过滤特定 PID
    u64 target = TARGET_PID;
    if (target && pid != target) return 0;
    
    u64 slot = bpf_log2l(PT_REGS_RC(ctx));
    dist.increment(slot);
    return 0;
}
"""
prog = prog.replace("TARGET_PID", str(target_pid))
b = BPF(text=prog)

# 绑定 kprobe
b.attach_kprobe(event="vfs_read", fn_name="do_trace")

# 输出直方图（每 2 秒）
try:
    while True:
        b["dist"].print_log2_hist("read() size")
        b["dist"].clear()
        time.sleep(2)
except KeyboardInterrupt:
    pass

# Step 1: 确认延迟层
$ bpftrace -e 'kprobe:blk_mq_start_request { @qstart[arg0] = nsecs; }
              kprobe:blk_mq_end_request /@qstart[arg0]/
              { @bio_lat = hist((nsecs - @qstart[arg0]) / 1000); delete(@qstart[arg0]); }'
# → 发现 bio 层延时集中在 32ms-256ms 桶
# → 不是块设备层问题（平均 < 5ms），而是队列等待

# Step 2: 锁定是 CPU 饱和还是锁争用
$ bpftrace -e 'tracepoint:sched:sched_switch /prev_state==0/ 
              { @start[pid] = nsecs; }
              sched:sched_switch /@start[pid]/ 
              { @sched_lat = hist((nsecs - @start[pid]) / 1000); delete(@start[pid]); }'
# → 调度延迟 < 200us，排除 CPU 过载

# Step 3: 检查 fsync 频率（MySQL redo log _checkpoint_）
$ bpftrace -e 'kprobe:vfs_fsync_range { @[comm, pid] = count(); }
              interval:s:5 { print(@); clear(@); }'
# → 发现 mysqld 每秒 fsync 200 次（正常 < 20 次）
# → 原因：innodb_flush_log_at_trx_commit=1 + 批量提交不足

# 根因：redo log 过小 → 频繁 checkpoint → 大量 fsync → 写入阻塞
# 解决：增加 innodb_log_file_size，开启 group commit

# 追踪 upstream 响应时间分布
$ bpftrace -e '
uprobe:/usr/sbin:ngx_http_upstream_connect { @start[pid] = nsecs; }
uretprobe:/usr/sbin:ngx_http_upstream_finalize_request /@start[pid]/
{ $dur = nsecs - @start[pid];
  @upstream_lat = hist($dur / 1000000);  // ms
  delete(@start[pid]); }'

# 同时追踪 upstream TCP 发送延迟
$ bpftrace -e 'kprobe:tcp_sendmsg /comm=="nginx"/
              { s[arg0] = nsecs; }
              kretprobe:tcp_sendmsg /s[arg0]/
              { @send = hist((nsecs - s[arg0]) / 1000); delete(s[arg0]); }'

# 发现：上游 PHP-FPM 进程池耗尽 → 请求排队
# → 长尾来自 PHP-FPM 的 accept 队列溢出
# 解决：增加 pm.max_children，开启慢日志定位慢请求

# 追踪 cgroup CPU 节流事件
$ bpftrace -e 'tracepoint:cgroup:cgroup_throttle 
              { printf("cgroup %d throttled for %d ns\n", 
                       args->css->cgroup->id, args->nr_periods * args->period); }'

# 或查看 CFS 带宽控制统计
$ cat /sys/fs/cgroup/cpu/kubepods/podXXX/cpu.stat
# nr_periods    172  （被节流周期数）
# nr_throttled  89   （被节流次数）
# throttled_time 2.3e9（纳秒，=2.3s）

# 根因：CPU burst 后触发限流 → 建议调高 CPU limit 或开启 cpu.cfs_burst_us

# 查看当前限制
$ ulimit -l   # 通常 64 (KB)

# 临时提升
$ ulimit -l unlimited

# Docker 方案（在容器内运行 BPF）
$ docker run --ulimit memlock=-1:-1 --privileged ...

# 推荐方案（无需特权）：使用 CAP_BPF + CAP_PERFMON
$ docker run --cap-add=BPF --cap-add=PERFMON ...
# Linux 5.8+: CAP_BPF 替代 CAP_SYS_ADMIN（特权分离更细粒度）