第3章：性能分析——BPF视角下的系统诊断方法论

没有方法论的工具只是玩具——BPF的屠龙之术需要USE、RED和火焰图这三把钥匙来解锁，否则你只是在内核的草原上盲目奔跑。

---

故事场景：那一万台服务器中的一次"慢"

周一早上，小李收到了一封来自客服转发的用户投诉："我在你们APP上点击购买，白屏了15秒。"

"15秒？"小李立刻打开监控大盘。QPS平稳、错误率正常、P99是500ms。没有任何异常。

"个体用户的偶发延迟，监控盲区，"小李嘟囔着准备回复"建议用户检查网络"。

老张正好路过，看了一眼投诉时间戳："等等，这个用户是VIP，而且投诉时间是昨晚8:47——大促开始前的预热期。"

"那又怎样？大盘没问题啊。"

"大盘的平均值掩盖了尾部的尾巴。"老张打开了几个终端窗口："来，我们用BPF做一次60秒全面体检，然后下钻。"

十分钟后，他们发现了真相：某台数据库主机的SSD进入了垃圾回收周期，导致一小部分用户的查询延迟飙升——这个主机只承载了0.3%的流量，但正好影响了这个VIP用户。

"性能分析不是看大盘有没有报警，"老张说，"它是关于量化目标、刻画负载、下钻根因的系统工程。"

---

一、性能目标量化：从"快不快"到"多快算够快"

1.1 延迟（Latency）的精确语义

在性能领域，"延迟"不是一个模糊的概念——它有不同的测量维度和统计表达。

延迟的测量层次：

┌─────────────────────────────────────────────────────────────┐
│ 应用层延迟: 用户点击 → 浏览器收到首字节 (TTFB)            │
│              = DNS + TCP握手 + TLS + 服务端处理 + 传输      │
├─────────────────────────────────────────────────────────────┤
│ 服务层延迟: 请求到达负载均衡 → 服务返回响应                 │
│              = 队列等待 + 业务逻辑 + RPC调用 + 数据库查询    │
├─────────────────────────────────────────────────────────────┤
│ 系统调用层: 进程进入内核 → 内核返回结果                     │
│              = 上下文切换 + VFS + 文件系统 + 块设备 + 驱动   │
├─────────────────────────────────────────────────────────────┤
│ 硬件层延迟: CPU执行指令 / 内存访问 / 磁盘寻道 / 网络传输    │
│              = 时钟周期 + CAS延迟 + 寻道时间 + RTT           │
└─────────────────────────────────────────────────────────────┘

BPF工具通常工作在系统调用层和内核层，这是应用监控无法触及的"地下世界"。

# 用BPF测量execve系统调用的延迟分布
/usr/share/bcc/tools/funccount 't:syscalls:sys_enter_execve'
/usr/share/bcc/tools/funccount 't:syscalls:sys_exit_execve'

# 或者用直方图
/usr/share/bcc/tools/funclatency '__x64_sys_openat' -u

1.2 百分位数：为什么P99比平均值诚实

// 用BPF Map实现一个简单的延迟直方图
BPF_HISTOGRAM(latency, u64, 64);  // 64个桶，对数刻度

int trace_exit(struct pt_regs *ctx) {
    u64 *start = starts.lookup(&pid);
    if (start) {
        u64 delta = bpf_ktime_get_ns() - *start;
        // 将纳秒转换为微秒，取log2分到64个桶
        u64 bucket = bpf_log2l(delta / 1000);
        if (bucket >= 64) bucket = 63;
        latency.increment(bucket);
    }
    return 0;
}

graph TD
    A["延迟样本流"] -->|"BPF采集"| B["实时直方图"]
    B --> C["Map: bucket->count"]
    C -->|"用户态读取"| D["计算百分位数"]
    D --> E["P50: 中位数"]
    D --> F["P90: 90%用户"]<-->G["1秒"]
    D --> H["P99: 尾部1%"]<-->I["15秒!!!"]
    D --> J["P99.9: 极端尾部"]
    
    style I fill:#ff6b6b,stroke:#333,stroke-width:2px,color:#fff
    style G fill:#4ecdc4,stroke:#333,stroke-width:2px,color:#fff

小李的认知升级："平均值就像把 Bill Gates 和一个普通人的收入平均一下——所有人都是亿万富翁。P99才是那些真实等待的用户的叹息。"

1.3 吞吐率（Throughput）与利用率（Utilization）

指标	定义	BPF测量方式
吞吐率	单位时间完成的请求/操作数	统计事件触发次数
利用率	资源忙碌时间占比	测量on-CPU时间 / wall-clock时间
饱和度	请求排队程度	测量队列长度或等待时间

# 用BCC的runqlat测量CPU调度队列延迟——直接反映CPU饱和度
/usr/share/bcc/tools/runqlat 10 1

# 输出示例：
# usecs               : count     distribution
#     0 -> 1          : 234      |********************|
#     2 -> 3          : 45       |****                |
#     4 -> 7          : 12       |*                   |
# 大量样本集中在0-1us = CPU充足；如果右侧有长尾 = CPU饱和

---

二、负载画像：理解你的系统"平时在忙什么"

2.1 什么是负载画像（Workload Characterization）

负载画像的核心问题：系统在常态下的工作模式是什么？ 如果不理解常态，就无法识别异常。

graph LR
    A["负载画像"] --> B["谁? 进程/用户/容器ID"]
    A --> C["做什么? 系统调用/文件/网络"]
    A --> D["怎么做? 读多写少?随机顺序?"]
    A --> E["多快? 频率/吞吐/延迟分布"]
    A --> F["什么时候? 时间模式/突发/周期"]

2.2 BPF在负载画像中的角色

# === CPU画像 ===
# 1. 哪个进程在消耗CPU？
/usr/share/bcc/tools/cpudist -P  # 每个进程的on-CPU时间分布

# 2. 它们在执行什么代码？
/usr/share/bcc/tools/profile -F 99 -p PID  # 火焰图采样

# === 文件系统画像 ===
# 3. 哪些文件被频繁访问？
/usr/share/bcc/tools/fileslower  # 跟踪慢于阈值的所有文件操作

# 4. 访问模式是顺序还是随机？
/usr/share/bcc/tools/biolatency -F  # 块设备IO延迟分布

# === 网络画像 ===
# 5. 连接模式如何？
/usr/share/bcc/tools/tcplife  # TCP连接生命周期

# 6. 流量流向哪里？
/usr/share/bcc/tools/tcpconnect  # TCP连接目标统计

// 负载画像BPF程序的核心逻辑——以文件访问为例
struct file_key_t {
    u32 pid;
    char comm[16];
    char filename[64];
};

BPF_HASH(file_access, struct file_key_t, u64);

int trace_vfs_read(struct pt_regs *ctx, struct file *file) {
    struct file_key_t key = {};
    key.pid = bpf_get_current_pid_tgid() >> 32;
    bpf_get_current_comm(&key.comm, sizeof(key.comm));
    
    // 从file结构体读取文件名
    bpf_probe_read_kernel_str(&key.filename, sizeof(key.filename), 
                              file->f_path.dentry->d_name.name);
    
    u64 *val = file_access.lookup(&key);
    if (val) (*val)++;
    else file_access.update(&key, &(u64){1});
    
    return 0;
}

---

三、下钻分析（Drill-down）：从症状到根因

3.1 下钻分析的逻辑树

graph TD
    A["用户抱怨: \"系统慢\""] --> B{哪个资源饱和?}
    B -->|"CPU高"| C["runqlat高?"]
    C -->|"是"| D["调度问题: 优先级/绑核/干扰"]
    C -->|"否"| E["计算密集型: 火焰图找热点"]
    
    B -->|"内存高"| F["内存用于?"]
    F -->|"缓存"| G["缓存命中率?"]
    F -->|"匿名"| H["泄漏? / 正常增长?"]
    F -->|swap| I["swappiness/NUMA不平衡"]
    
    B -->|"IO高"| J{磁盘/网络/文件?}
    J -->|"磁盘"| K["队列深度?随机/顺序?"]
    J -->|"网络"| L["TCP重传?拥塞?带宽?"]
    
    B -->|"都不是"| M["锁竞争? off-CPU分析"]
    M --> N["同步原语: mutex/rwsem/futex"]
    
    style A fill:#ff6b6b,stroke:#333,stroke-width:2px,color:#fff

3.2 BPF的下钻利器：off-CPU分析

CPU分析（火焰图）只看"进程在CPU上时做了什么"。但很多时候，问题的根因是进程不在CPU上时发生了什么——这就是off-CPU分析（Off-CPU Analysis，Off-CPU分析）。

graph LR
    A["进程生命周期"] -->|on-CPU| B["执行计算"]
    B -->|yield/sleep/block| C[off-CPU]
    C -->|"为什么离开?"| D["调度器决策"]
    D -->|"原因1"| E["主动放弃: nanosleep/yield"]
    D -->|"原因2"| F["锁等待: mutex/futex/rwsem"]
    D -->|"原因3"| G["IO等待: read/write/blockdev"]
    D -->|"原因4"| H["内存等待: page fault/swap"]
    D -->|"原因5"| I["中断/信号处理"]
    
    style C fill:#ffd93d,stroke:#333,stroke-width:2px
    style F fill:#ff6b6b,stroke:#333,stroke-width:2px,color:#fff
    style G fill:#ff6b6b,stroke:#333,stroke-width:2px,color:#fff

# 使用BCC的offcputime工具——火焰图的另一面
/usr/share/bcc/tools/offcputime -p PID -f 30 > offcpu.stacks
cat offcpu.stacks | flamegraph.pl > offcpu.svg

# off-CPU火焰图的阅读：
# - 宽度 = 不在CPU上的总时间
# - 栈顶 = 阻塞的系统调用/锁
# - 栈底 = 业务代码的调用链

---

四、两大黄金方法论：USE与RED

4.1 USE方法：资源视角的诊断框架

USE（Utilization-Saturation-Errors，利用率-饱和度-错误）方法由Brendan Gregg提出，它要求对系统的每一种资源检查三个指标：

指标	含义	BPF工具示例
Utilization 利用率	资源忙碌时间比例	runqlat → CPU利用率；biolatency → 磁盘利用率
Saturation 饱和度	请求因资源繁忙而排队的程度	runqlat长尾 → CPU饱和；块设备队列深度 → IO饱和
Errors 错误	错误事件计数	ext4slower中的错误返回；TCP重传计数

graph TD
    subgraph "CPU资源"
        A1[Utilization] -->|"on-CPU时间"| B1[profile/runqlat]
        C1[Saturation] -->|"调度队列等待"| D1["runqlat > 阈值"]
        E1[Errors] -->|"上下文切换失败"| F1["调度器错误"]
    end
    subgraph "内存资源"
        A2[Utilization] -->|"已用内存"| B2[memleak]
        C2[Saturation] -->|"swap活动"| D2["swapin延迟"]
        E2[Errors] -->|"OOM/分配失败"| F2["alloc失败计数"]
    end
    subgraph "磁盘资源"
        A3[Utilization] -->|"活跃时间"| B3[biolatency]
        C3[Saturation] -->|"队列深度"| D3["iostat -x"]
        E3[Errors] -->|"IO错误"| F3["biosnoop中的错误码"]
    end
    subgraph "网络资源"
        A4[Utilization] -->|"带宽使用"| B4[tcptop]
        C4[Saturation] -->|"TCP重传/RTO"| D4[tcpretrans]
        E4[Errors] -->|"连接失败/超时"| F4["syscount网络错误"]
    end

# USE方法的BPF工具检查清单（60秒版）

# CPU
/usr/share/bcc/tools/runqlat 1 10          # 饱和度：调度延迟
/usr/share/bcc/tools/profile -F 99 10      # 利用率：热点函数

# 内存
/usr/share/bcc/tools/funccount 't:kmem:kmem_cache_alloc'  # 分配频率
/usr/share/bcc/tools/memleak -p PID 10     # 泄漏追踪

# 磁盘
/usr/share/bcc/tools/biolatency 10 1       # IO延迟分布
/usr/share/bcc/tools/biosnoop 10           # 每个IO的详细信息

# 网络
/usr/share/bcc/tools/tcplife 10            # TCP连接统计
/usr/share/bcc/tools/tcpretrans 10         # 重传探测

4.2 RED方法：服务视角的微服务框架

RED（Rate-Errors-Duration，速率-错误-持续时间）方法是针对服务/应用的诊断框架，特别适用于微服务架构：

指标	含义	BPF视角
Rate 速率	每秒请求数	统计进入服务的系统调用频率
Errors 错误	失败请求比例	追踪返回错误码的系统调用
Duration 持续时间	每个请求的耗时	测量关键函数入口到出口的延迟

// RED方法的BPF实现——以HTTP服务为例
struct event_t {
    u64 latency_us;
    u32 pid;
    u32 status_code;
    char path[128];
};

BPF_RINGBUF_OUTPUT(events, 1024);
BPF_HASH(starts, u64, u64);  // tid -> timestamp

int trace_http_request_entry(struct pt_regs *ctx) {
    u64 tid = bpf_get_current_pid_tgid();
    u64 ts = bpf_ktime_get_ns();
    starts.update(&tid, &ts);
    return 0;
}

int trace_http_request_exit(struct pt_regs *ctx) {
    u64 tid = bpf_get_current_pid_tgid();
    u64 *start = starts.lookup(&tid);
    if (!start) return 0;
    
    struct event_t event = {};
    event.latency_us = (bpf_ktime_get_ns() - *start) / 1000;
    event.pid = tid >> 32;
    // 从ctx/寄存器提取HTTP状态码和路径...
    
    events.ringbuf_output(&event, sizeof(event), 0);
    starts.delete(&tid);
    return 0;
}

graph LR
    subgraph "RED微服务监控"
        A[Rate] -->|QPS| B["BPF统计请求入口"]
        C[Errors] -->|5xx/timeout| D["BPF跟踪返回码"]
        E[Duration] -->|P50/P99| F["BPF测量函数延迟"]
    end
    G["聚合"] -->|Prometheus| H["RED仪表盘"]
    B & D & F --> G

---

五、Linux 60秒分析与BCC检查清单

5.1 60秒体检：快速定位问题象限

#!/bin/bash
# Linux 60秒性能分析脚本——BCC/BPF工具版
# 来自《BPF之巅》方法论的核心实践

echo "=== 1-10秒: 系统概览 ==="
vmstat 1 10      # r列高 = CPU饱和; si/so高 = 内存压力; us/sy/id = CPU使用分布

echo "=== 10-20秒: CPU画像 ==="
/usr/share/bcc/tools/runqlat 1 10
# 如果平均延迟 > 10ms，说明CPU调度有压力

echo "=== 20-30秒: IO画像 ==="
/usr/share/bcc/tools/biolatency 10 1
# 注意延迟分布的尾部——长尾意味着设备压力

echo "=== 30-40秒: 网络画像 ==="
/usr/share/bcc/tools/tcplife 10
# 观察是否有异常的短连接（大量TIME_WAIT）或长连接 hang

echo "=== 40-50秒: 文件系统画像 ==="
/usr/share/bcc/tools/ext4slower 10
# 跟踪慢于10ms的文件系统操作

echo "=== 50-60秒: 火焰图采样 ==="
/usr/share/bcc/tools/profile -F 99 10 > /tmp/profile.stacks
# 后续可生成火焰图查看热点

5.2 BCC工具检查清单（按资源分类）

graph TD
    A["BCC工具检查清单"] --> B[CPU]
    B --> B1["profile - 火焰图"]
    B --> B2["runqlat - 调度延迟"]
    B --> B3["cpudist - CPU时间分布"]
    B --> B4["offcputime - 阻塞火焰图"]
    
    A --> C["内存"]
    C --> C1["memleak - 内存泄漏"]
    C --> C2["syscount - 系统调用统计"]
    C --> C3["vmscan - 页回收"]
    
    A --> D["文件系统"]
    D --> D1["ext4slower - 慢操作"]
    D --> D2["btrfsdist - 延迟分布"]
    D --> D3["filetop - 热点文件"]
    
    A --> E["磁盘IO"]
    E --> E1["biolatency - IO延迟"]
    E --> E2["biosnoop - 每个IO跟踪"]
    E --> E3["iolatency - 设备级延迟"]
    
    A --> F["网络"]
    F --> F1["tcplife - 连接生命周期"]
    F --> F2["tcpretrans - 重传分析"]
    F --> F3["tcpconnect - 连接统计"]
    F --> F4["funccount套接字函数"]
    
    A --> G["安全"]
    G --> G1["execsnoop - 进程执行"]
    G --> G2["opensnoop - 文件打开"]
    G --> G3["syscount - 异常系统调用"]

# BCC检查清单速查表

# CPU
bcc-profile       # on-CPU火焰图
bcc-runqlat       # 调度队列延迟
bcc-runqlen       # 调度队列长度
bcc-cpudist       # 每个任务的CPU时间分布

# 内存
bcc-memleak       # 用户/内核态内存泄漏追踪
bcc-vmscan        # 内存页回收活动
bcc-swapin        # swapin延迟

# 文件系统
bcc-ext4dist      # ext4操作延迟分布
bcc-ext4slower    # 跟踪慢ext4操作
bcc-filetop       # 文件读写排行

# 磁盘
bcc-biolatency    # 块设备IO延迟
bcc-biosnoop      # 逐IO跟踪
bcc-biotop        # IO操作排行

# 网络
bcc-tcplife       # TCP连接生命周期（建立→关闭）
bcc-tcpretrans    # TCP重传探测
bcc-tcpconnect    # TCP连接发起统计
bcc-tcptop        # TCP吞吐量排行

# 通用
bcc-execsnoop     # 新进程执行追踪
bcc-opensnoop     # 文件打开追踪
bcc-syscount      # 系统调用频率统计
bcc-funccount     # 任意函数调用计数

---

总结

graph TD
    A["性能分析方法论"] --> B["量化目标"]
    B --> B1["延迟: P99 > 平均值"]
    B --> B2["吞吐: QPS/TPS"]
    B --> B3["利用率: 资源忙碌比例"]
    
    A --> C["负载画像"]
    C --> C1["谁/做什么/怎么做/多快/何时"]
    C --> C2["BPF工具: profile/biolatency/tcplife"]
    
    A --> D["下钻分析"]
    D --> D1["CPU? → 火焰图"]
    D --> D2["IO? → biolatency"]
    D --> D3["锁? → off-CPU火焰图"]
    D --> D4["内存? → memleak/vmscan"]
    
    A --> E["USE方法"]
    E --> E1["Utilization: 利用率"]
    E --> E2["Saturation: 饱和度"]
    E --> E3["Errors: 错误计数"]
    
    A --> F["RED方法"]
    F --> F1["Rate: 每秒请求"]
    F --> F2["Errors: 失败比例"]
    F --> F3["Duration: 请求耗时"]
    
    A --> G["60秒检查"]
    G --> G1["vmstat + runqlat + biolatency"]
    G --> G2["tcplife + ext4slower + profile"]

核心要点

1. 量化是一切的基础："慢"不是一个问题描述，"P99延迟从200ms上升到15秒"才是。BPF的直方图Map是采集延迟分布的最佳工具。
2. 负载画像先于异常检测：不知道"平时"长什么样，就无法识别"异常"。BPF的低开销使全量采集成为可能。
3. 下钻是树形搜索：从"系统慢"到"SSD垃圾回收导致ext4延迟飙升"，需要沿着资源维度逐层分解。
4. USE方法看资源：对每种资源（CPU/内存/磁盘/网络），检查利用率、饱和度、错误三个维度。
5. RED方法看服务：对微服务，检查速率（Rate）、错误（Errors）、持续时间（Duration）。
6. 60秒检查清单是武器库：vmstat → runqlat → biolatency → tcplife → ext4slower → profile，六步覆盖六大资源。
7. off-CPU分析是隐藏宝藏：进程不在CPU上的时间往往比on-CPU时间更能揭示根因——锁等待、IO阻塞、内存缺页，都在这部分。

小李后来把那套60秒检查清单写进了团队的On-call手册。"以前遇到性能问题，我们像无头苍蝇一样到处尝试，"他在团队分享会上说，"现在我知道了——先画像、再量化、再下钻。BPF不是让你跑得更快，而是让你知道该往哪里跑。"

---

本章完。下一章开始按资源维度深入：第4章——CPU分析。