利用 `perf` 与 `eBPF` 监控 C++ 进程：如何实时分析生产环境下的内核锁争用情况？

各位同仁，大家好。今天我们将深入探讨一个在高性能C++应用开发和运维中至关重要的议题：如何在生产环境下，利用强大的 perf 工具和革命性的 eBPF 技术，实时监控并分析内核锁争用情况。

在构建高并发、低延迟的C++服务时，我们常常将注意力集中在用户态代码的优化上，例如无锁数据结构、线程池、异步I/O等。然而，当我们的应用程序与操作系统内核频繁交互时，例如进行大量系统调用、文件I/O、网络通信、内存分配等，就有可能触发内核内部的锁机制。如果这些内核锁成为瓶颈，即使用户态代码再优化，整体性能也可能不尽如人意。尤其在多核CPU系统上，内核锁争用可能导致严重的性能下降，表现为系统CPU使用率高（尤其在系统态）、延迟增加、吞吐量下降。

理解并解决内核锁争用，是优化生产系统性能的关键一环。今天，我们将学习如何利用Linux系统提供的最先进的工具，获取这种深度洞察。

内核锁争用：C++应用的隐形杀手

首先，让我们明确什么是内核锁争用，以及它如何影响我们的C++应用。

什么是内核锁？

Linux内核为了保护其内部数据结构的一致性，防止多个CPU或中断同时访问和修改，使用了各种同步机制，统称内核锁。常见的内核锁类型包括：

• 自旋锁 (Spinlock): 当一个CPU尝试获取一个已被持有的自旋锁时，它会忙等待（自旋），直到锁被释放。适用于锁持有时间非常短的场景，因为忙等待避免了上下文切换的开销。
• 互斥锁 (Mutex): 如果一个CPU尝试获取已被持有的互斥锁，它会进入睡眠状态，直到锁被释放并被唤醒。适用于锁持有时间较长的场景，避免了忙等待的CPU浪费。
• 读写信号量 (RW-Semaphore): 允许多个读者同时持有锁，但只允许一个写者持有锁。写者会阻塞所有读者和写者，读者会阻塞写者。
• RCU (Read-Copy-Update): 一种无锁的读机制，允许读者在没有锁的情况下访问数据，而写者在修改数据时创建副本，并在修改完成后原子地替换旧数据。RCU的争用表现形式与传统锁不同，通常是写者竞争RCU宽限期。

C++应用如何触发内核锁？

我们的C++应用本身不会直接操作内核锁（除非编写内核模块）。但是，当应用执行某些操作时，会通过系统调用（syscall）进入内核态，进而可能触发内核锁。常见场景包括：

• 文件I/O: read(), write(), open(), close(), fsync() 等操作会涉及文件系统内部的数据结构（如inode、dentry缓存、页缓存），这些数据结构都受到内核锁保护。
• 网络I/O: send(), recv(), accept(), connect() 等操作会涉及网络协议栈内部的数据结构（如socket、TCP连接状态），同样受到内核锁保护。
• 内存管理: mmap(), munmap(), brk() 等内存分配和释放操作，以及页错误（page fault）处理，会涉及MMU（内存管理单元）和页表操作，这些都可能触发内核锁。
• 进程/线程管理: fork(), clone(), execve(), exit(), wait() 等操作会涉及进程调度器、进程描述符等核心数据结构。
• IPC (进程间通信): 管道、消息队列、共享内存、信号量等机制的实现也依赖于内核锁。
• 上下文切换: 当一个CPU从一个进程切换到另一个进程时，调度器本身也会使用锁。

当多个线程或进程频繁地通过系统调用访问相同的内核资源时，就会导致这些内核锁的争用，从而降低并发性能。

争用的症状

在生产环境中，内核锁争用的典型症状包括：

• 高系统CPU使用率: top 或 htop 显示 %sy 很高，但应用程序的用户态CPU使用率 %us 并不一定很高。
• 延迟飙升: 请求处理时间变得不稳定，出现长尾延迟。
• 吞吐量下降: 即使增加并发，系统的处理能力也无法线性提升，甚至可能下降。
• dmesg 或 /var/log/kern.log 中出现软死锁 (softlockup) 警告: 这通常是自旋锁长时间被持有的极端情况。

第一部分：perf – Linux性能分析的瑞士军刀

perf 是Linux内核自带的性能分析工具，它通过采样（sampling）和跟踪（tracing）机制，能够深入了解CPU、内存、I/O等各个层面的性能瓶颈。对于发现内核锁争用，perf 是一个非常有效的起点。

perf 概览

perf 的核心功能包括：

• 事件计数 (Counting): 统计特定事件（如CPU周期、指令数、缓存未命中、系统调用等）发生的次数。
• 采样 (Sampling): 在特定事件发生时（例如每1000个CPU周期），记录当前的执行上下文（程序计数器、调用栈）。这是发现热点代码的关键。
• 跟踪 (Tracing): 记录内核中的特定事件，如调度事件、文件I/O事件、系统调用等。
• 硬件性能计数器 (Hardware Performance Counters – HPCs): 利用CPU内置的计数器，测量如指令退休数、缓存命中/未命中等低级硬件事件。

使用 perf stat 概览系统健康

perf stat 可以提供一个高层次的系统性能概览，帮助我们判断是否存在潜在的内核瓶颈。

# 监控整个系统的统计信息，持续5秒
sudo perf stat -a sleep 5

# 监控特定C++进程（PID为12345）的统计信息
sudo perf stat -p 12345 sleep 5

输出示例（部分）：

 Performance counter stats for system wide (5 seconds):

       69,321.41 msec cpu-clock                #    13.864 CPUs utilized
       2,349.33      context-switches         #    0.000 M/sec
          43.32      cpu-migrations           #    0.000 M/sec
          80.00      page-faults              #    0.000 M/sec
 1,821,570,392.00      cycles                   #  364.314 GHz                      (83.33%)
 1,514,637,428.00      instructions             #    0.83 instr per cycle           (83.33%)
   416,560,000.00      branches                 #   83.312 GHz                      (83.33%)
     5,830,683.00      branch-misses            #    1.40% of all branches          (83.33%)

  5.001602330 seconds time elapsed

关键指标：

• cpu-clock: CPU消耗的总时间。如果远大于实际经过的时间，表示系统是多核的，并且CPU利用率高。
• context-switches: 上下文切换的次数。高频率的上下文切换可能表示线程/进程竞争激烈，也可能是因为锁争用导致线程休眠唤醒。
• page-faults: 缺页中断次数。大量缺页中断可能表示内存访问模式不佳或内存压力大。
• cycles, instructions, branch-misses: 这些硬件计数器可以提供更底层的CPU效率信息。

如果 context-switches 很高，或者 cpu-clock 在系统态的比例很高，那么内核锁争用的可能性就增加了。

使用 perf record 和 perf report 识别热点

perf stat 提供了宏观视图，但要找出具体的争用点，我们需要 perf record 进行采样，然后用 perf report 进行分析。

perf record 会以一定频率对CPU活动进行采样，记录采样点发生时的程序计数器和调用栈。通过分析这些采样数据，我们可以找出CPU时间花费最多的代码路径，包括用户态和内核态。

示例C++代码：模拟文件I/O争用

假设我们有一个简单的C++程序，多个线程同时对同一个文件进行写操作，这可能会导致文件系统层面的内核锁争用。

// file_writer.cpp
#include <iostream>
#include <fstream>
#include <vector>
#include <thread>
#include <string>
#include <chrono>
#include <atomic>

// 全局原子计数器，用于控制写入的行数
std::atomic<long> line_counter(0);
const long MAX_LINES = 1000000; // 写入总行数

void write_to_file(const std::string& filename, int thread_id) {
    std::ofstream ofs(filename, std::ios::app); // 以追加模式打开
    if (!ofs.is_open()) {
        std::cerr << "Thread " << thread_id << ": Failed to open file " << filename << std::endl;
        return;
    }

    std::string line_prefix = "Thread " + std::to_string(thread_id) + ": Line ";

    while (true) {
        long current_line = line_counter.fetch_add(1);
        if (current_line >= MAX_LINES) {
            break;
        }
        // 每次写入一行并强制刷新，增加系统调用和潜在的内核锁争用
        ofs << line_prefix << current_line << std::endl;
        ofs.flush(); // 强制刷新到磁盘，增加I/O操作
    }
    ofs.close();
    std::cout << "Thread " << thread_id << " finished writing." << std::endl;
}

int main() {
    const std::string filename = "output.log";
    const int num_threads = 8; // 8个线程并发写入

    // 清空文件内容
    std::ofstream clear_ofs(filename, std::ios::trunc);
    clear_ofs.close();

    std::vector<std::thread> threads;
    auto start_time = std::chrono::high_resolution_clock::now();

    for (int i = 0; i < num_threads; ++i) {
        threads.emplace_back(write_to_file, filename, i);
    }

    for (auto& t : threads) {
        t.join();
    }

    auto end_time = std::chrono::high_resolution_clock::now();
    std::chrono::duration<double> diff = end_time - start_time;
    std::cout << "Total lines written: " << MAX_LINES << std::endl;
    std::cout << "Total time taken: " << diff.count() << " seconds" << std::endl;

    return 0;
}

编译并运行这个程序：

g++ -std=c++17 -pthread -o file_writer file_writer.cpp
./file_writer & # 在后台运行，以便perf监控

获取 file_writer 进程的PID。然后使用 perf record 监控它：

# 假设file_writer的PID是12345
sudo perf record -F 99 -g -p 12345 -- sleep 10
# -F 99: 每秒采样99次
# -g: 记录调用图（call graph），这对于理解代码路径至关重要
# -p 12345: 监控PID为12345的进程
# -- sleep 10: 监控10秒，然后停止

perf record 会生成一个 perf.data 文件。现在，使用 perf report 分析数据：

sudo perf report -g

perf report 会打开一个交互式界面，显示CPU时间花费最多的函数。你会看到一个类似下面的表格：

Overhead	Command	Shared Object	Symbol
25.12%	file_writer	[kernel.kallsyms]	__raw_spin_lock_irqsave
18.75%	file_writer	[kernel.kallsyms]	_raw_spin_unlock_irqrestore
12.30%	file_writer	[kernel.kallsyms]	fsync_bdev
9.87%	file_writer	[kernel.kallsyms]	__sync_page_range
7.15%	file_writer	file_writer	write_to_file
5.43%	file_writer	[kernel.kallsyms]	ext4_file_fsync
3.21%	file_writer	[kernel.kallsyms]	sys_fsync
…	…	…	…

分析 perf report 输出：

1. Overhead: 表示该函数或符号占总CPU时间的百分比。
2. Shared Object:
   • [kernel.kallsyms] 表示该符号是内核函数。
   • file_writer 表示该符号是用户态 file_writer 程序中的函数。
3. Symbol: 函数名。

从上面的示例中，我们可以清晰地看到：

• 大量的CPU时间花费在 [kernel.kallsyms] 中的函数上，特别是 __raw_spin_lock_irqsave 和 _raw_spin_unlock_irqrestore。这直接指向了内核自旋锁的获取和释放，表明存在严重的内核锁争用。
• fsync_bdev, __sync_page_range, ext4_file_fsync, sys_fsync 等函数也占据了大量CPU时间。这些都是文件系统同步和I/O相关的内核函数。
• 用户态的 write_to_file 函数虽然也有一定开销，但相比内核态的锁和I/O操作，其占比明显较低。

结论： 我们的C++程序由于频繁调用 ofs.flush() 导致 fsync 系统调用，进而触发了文件系统层面的内核锁（例如inode锁、页缓存锁），多个线程并发争用这些锁导致性能瓶颈。

在 perf report 界面中，你可以选择一个内核函数（例如 __raw_spin_lock_irqsave），然后按 a 键查看其详细的调用栈。这能帮助你追溯到是哪个用户态函数导致了这些内核调用。

perf script 进行自定义分析

perf report 提供了强大的交互式视图，但有时我们需要更灵活的、可编程的分析方式。perf script 可以将 perf.data 中的原始采样数据导出为可解析的文本格式，然后我们可以使用脚本（如Python、awk）进行自定义处理。

# 导出perf.data中的事件为可读文本
sudo perf script > perf.txt

perf.txt 文件会包含每条采样记录的详细信息，包括PID、线程ID、CPU、时间戳、事件类型以及完整的调用栈。我们可以编写脚本来解析这个文件，例如，统计哪些内核锁函数被调用最多，或者计算锁的平均持有时间（如果事件提供了足够的信息）。

例如，要统计 __raw_spin_lock_irqsave 的调用次数：

grep "__raw_spin_lock_irqsave" perf.txt | wc -l

虽然 perf script 提供了灵活性，但它通常用于后处理。对于实时、精细的内核行为追踪，eBPF 提供了更强大的能力。

第二部分：eBPF – 深入内核的编程能力

eBPF (extended Berkeley Packet Filter) 是一项革命性的Linux内核技术，它允许用户在不修改内核源码或加载内核模块的情况下，安全地在内核中运行自定义程序。eBPF 程序可以在内核的各种“挂钩点”上执行，例如系统调用入口/出口、函数调用/返回、网络事件、调度事件等。这使得 eBPF 成为实时监控、跟踪和调试内核行为的终极工具。

eBPF 核心概念

• BPF程序 (BPF Program): 用C语言编写（通常是BCC或libbpf），然后编译成BPF字节码，加载到内核中执行。
• 挂钩点 (Hook Points): eBPF 程序可以附加到内核的预定义点上，例如：
  • kprobes/kretprobes: 动态跟踪内核函数的入口和返回。
  • uprobes/uretprobes: 动态跟踪用户态函数的入口和返回。
  • tracepoints: 内核中预定义的稳定跟踪点，通常用于特定子系统。
  • perf events: 捕获硬件性能计数器事件或软件事件。
  • sockets/XDP/TC: 网络数据包处理。
• BPF映射 (BPF Maps): 内核态 eBPF 程序和用户态程序之间，或不同 eBPF 程序之间共享数据的机制。常见的映射类型有哈希表、数组、栈跟踪映射等。
• 辅助函数 (Helper Functions): eBPF 程序在内核中可以调用的预定义函数，例如读取进程上下文、获取时间戳、打印调试信息等。
• 安全性: eBPF 程序在加载到内核前会经过一个严格的验证器，确保程序不会导致内核崩溃、无限循环或访问非法内存。

eBPF 开发环境：BCC

BCC (BPF Compiler Collection) 是一个工具集，它简化了 eBPF 程序的编写。BCC 提供了一个Python（或Lua、C++）前端，允许开发者使用C语言编写 eBPF 内核部分，并使用Python编写用户态部分来加载、编译、执行 eBPF 程序并处理其输出。

安装 BCC (Ubuntu为例):

sudo apt update
sudo apt install bpfcc-tools linux-headers-$(uname -r) build-essential

使用现有 BCC 工具监控内核锁

BCC 提供了许多开箱即用的工具，其中一些可以直接用于检测内核锁争用。

1. locksnoop: 追踪内核锁事件

locksnoop 是一个非常有用的工具，它通过 kprobes 挂钩到内核的 mutex_lock、spin_lock 等函数，记录锁的获取和释放，并计算锁等待时间。

# 追踪所有进程的内核锁事件
sudo locksnoop

输出示例（部分）：

TIME     PID    COMM         TYPE     LOCK_ADDR         STATUS   DURATION_US
14:30:01 12345  file_writer  MUTEX    0xffff8881001e0d70 ACQUIRED 0.12
14:30:01 12345  file_writer  MUTEX    0xffff8881001e0d70 RELEASED 0.00
14:30:01 12345  file_writer  MUTEX    0xffff8881001e0d70 ACQUIRED 0.09
14:30:01 12346  file_writer  MUTEX    0xffff8881001e0d70 WAITING  15.34
14:30:01 12345  file_writer  MUTEX    0xffff8881001e0d70 RELEASED 0.00
14:30:01 12346  file_writer  MUTEX    0xffff8881001e0d70 ACQUIRED 0.11
...

分析 locksnoop 输出：

• PID, COMM: 进程ID和名称。
• TYPE: 锁的类型（MUTEX, SPIN等）。
• LOCK_ADDR: 锁在内核内存中的地址。相同的地址表示是同一个锁。
• STATUS: ACQUIRED (获取成功), RELEASED (释放), WAITING (等待锁)。
• DURATION_US: 如果是 ACQUIRED，表示获取锁到释放锁的持有时间；如果是 WAITING，表示等待锁的时间。

从 locksnoop 的输出中，我们可以清晰地看到 file_writer 进程中不同线程对同一个内核锁地址的 WAITING 记录，以及等待的时间。长时间的 WAITING 表明锁争用严重。通过 LOCK_ADDR 可以识别是哪个具体的内核锁实例发生了争用。

2. funclatency: 测量函数执行延迟

funclatency 可以测量特定内核函数的执行时间，这对于找出哪些操作耗时过长非常有帮助。我们可以用它来测量与锁相关的内核函数（如 mutex_lock, __raw_spin_lock_irqsave）的延迟。

# 测量内核函数 __raw_spin_lock_irqsave 的执行延迟
sudo funclatency __raw_spin_lock_irqsave

输出示例（部分）：

Tracing __raw_spin_lock_irqsave... Hit Ctrl-C to end.
     PID     COMM            AVG_US     MIN_US     MAX_US     COUNT
   12345   file_writer       2.50       0.10      120.00       5000
   12346   file_writer       3.10       0.15       90.00       4800
   ...

这个工具显示了指定函数在每个进程中的平均、最小、最大执行时间。如果这些与锁相关的函数的 MAX_US 或 AVG_US 很高，那说明锁的持有时间很长，或者等待时间很长（取决于被测函数）。

3. profile: 系统级CPU火焰图生成器

BCC 的 profile 工具可以生成系统范围的CPU使用率概览，并结合 FlameGraph 工具生成火焰图，直观展示CPU时间消耗。这与 perf record 类似，但 eBPF 版本的 profile 可以提供更细粒度的控制和更低的开销。

# 采样10秒，生成CPU火焰图数据
sudo profile -F 99 -f 10 > profile.txt

然后将 profile.txt 导入到 FlameGraph 工具生成SVG图像（需要安装FlameGraph工具集）。

# 从FlameGraph仓库中获取stackcollapse-perf.pl和flamegraph.pl
git clone --depth 1 https://github.com/brendangregg/FlameGraph
cd FlameGraph

# 将profile.txt转换为火焰图所需的格式
./stackcollapse-perf.pl ../profile.txt > collapsed.txt

# 生成SVG火焰图
./flamegraph.pl collapsed.txt > profile.svg

打开 profile.svg 文件，你会看到一个交互式图形。火焰图的宽度代表CPU时间的占比，高度代表调用栈深度。通过查看火焰图上最宽的“火焰”，并向下深入，你可以快速识别出哪些内核函数（特别是锁函数）是CPU时间的消耗大户。

定制化 eBPF 脚本监控内核锁

当现有工具无法满足需求时，我们可以编写自定义 eBPF 脚本。这里我们将创建一个Python脚本，利用 kprobes 跟踪 __raw_spin_lock_irqsave 和 _raw_spin_unlock_irqrestore，测量自旋锁的持有时间，并记录等待锁的进程。

eBPF C代码 (bpf_text)：

#include <uapi/linux/ptrace.h>
#include <linux/sched.h> // for TASK_COMM_LEN
#include <linux/pid.h>   // for pid_t

// 定义一个哈希映射，用于存储锁获取的开始时间
// 键是锁的地址，值是获取锁的时间戳（纳秒）
struct bpf_map_def SEC("maps") start_times = {
    .type = BPF_MAP_TYPE_HASH,
    .key_size = sizeof(u64),      // 锁的地址作为键
    .value_size = sizeof(u64),    // 开始时间戳作为值
    .max_entries = 1024,
};

// 定义一个事件结构体，用于将数据从内核发送到用户空间
struct lock_event {
    u32 pid;
    char comm[TASK_COMM_LEN];
    u64 lock_addr;
    u64 duration_ns; // 锁持有时间或等待时间
    u8 type;         // 0: lock acquired, 1: lock released, 2: lock contended
};

// 定义一个perf buffer，用于向用户空间发送事件
struct bpf_map_def SEC("maps") events = {
    .type = BPF_MAP_TYPE_PERF_EVENT_ARRAY,
    .key_size = sizeof(u32),
    .value_size = sizeof(u32),
    .max_entries = 0, // 动态大小
};

// kprobe for __raw_spin_lock_irqsave (lock acquisition attempt)
// This function attempts to acquire a spinlock.
// If it has to wait, it will spin.
SEC("kprobe/__raw_spin_lock_irqsave")
int kprobe_spin_lock(struct pt_regs *ctx) {
    u64 lock_addr = PT_REGS_PARM1(ctx); // 第一个参数是锁的地址
    u64 ts = bpf_ktime_get_ns();        // 获取当前时间戳

    // 尝试将锁地址和时间戳存入map
    // 如果map中已存在此锁地址（意味着另一个CPU正在持有或等待），则表明存在争用
    u64 *prev_ts = bpf_map_lookup_elem(&start_times, &lock_addr);
    if (prev_ts) {
        // 锁已经被持有，此进程在等待
        // 我们可以记录等待事件，但更准确的等待时间需要更复杂的逻辑（如调度器事件）
        // 这里简化为，只要map里有，就认为有争用
        struct lock_event event = {};
        event.pid = bpf_get_current_pid_tgid() >> 32;
        bpf_get_current_comm(&event.comm, sizeof(event.comm));
        event.lock_addr = lock_addr;
        event.duration_ns = ts - *prev_ts; // 粗略估计从上次记录到现在的等待时间
        event.type = 2; // Contended
        bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU, &event, sizeof(event));
    }

    // 将当前锁地址和时间戳存入map
    // 无论是否争用，我们都记录本次尝试获取锁的时间
    bpf_map_update_elem(&start_times, &lock_addr, &ts, BPF_ANY);

    return 0;
}

// kretprobe for _raw_spin_unlock_irqrestore (lock release)
// This function releases a spinlock.
SEC("kretprobe/_raw_spin_unlock_irqrestore")
int kretprobe_spin_unlock(struct pt_regs *ctx) {
    u64 lock_addr = PT_REGS_PARM1(ctx); // 第一个参数是锁的地址
    u64 *start_ts = bpf_map_lookup_elem(&start_times, &lock_addr);

    if (start_ts) {
        u64 duration_ns = bpf_ktime_get_ns() - *start_ts;

        struct lock_event event = {};
        event.pid = bpf_get_current_pid_tgid() >> 32;
        bpf_get_current_comm(&event.comm, sizeof(event.comm));
        event.lock_addr = lock_addr;
        event.duration_ns = duration_ns;
        event.type = 1; // Released

        bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU, &event, sizeof(event));

        bpf_map_delete_elem(&start_times, &lock_addr); // 从map中删除
    }
    return 0;
}

Python 用户态代码：

from bcc import BPF
import ctypes as ct
import sys
import time

# eBPF C code (same as above)
bpf_text = """
#include <uapi/linux/ptrace.h>
#include <linux/sched.h>
#include <linux/pid.h>

struct bpf_map_def SEC("maps") start_times = {
    .type = BPF_MAP_TYPE_HASH,
    .key_size = sizeof(u64),
    .value_size = sizeof(u64),
    .max_entries = 1024,
};

struct lock_event {
    u32 pid;
    char comm[TASK_COMM_LEN];
    u64 lock_addr;
    u64 duration_ns;
    u8 type;
};

struct bpf_map_def SEC("maps") events = {
    .type = BPF_MAP_TYPE_PERF_EVENT_ARRAY,
    .key_size = sizeof(u32),
    .value_size = sizeof(u32),
    .max_entries = 0,
};

SEC("kprobe/__raw_spin_lock_irqsave")
int kprobe_spin_lock(struct pt_regs *ctx) {
    u64 lock_addr = PT_REGS_PARM1(ctx);
    u64 ts = bpf_ktime_get_ns();

    u64 *prev_ts = bpf_map_lookup_elem(&start_times, &lock_addr);
    if (prev_ts) {
        struct lock_event event = {};
        event.pid = bpf_get_current_pid_tgid() >> 32;
        bpf_get_current_comm(&event.comm, sizeof(event.comm));
        event.lock_addr = lock_addr;
        event.duration_ns = ts - *prev_ts; // Contention duration
        event.type = 2; // Contended
        bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU, &event, sizeof(event));
    }

    bpf_map_update_elem(&start_times, &lock_addr, &ts, BPF_ANY);
    return 0;
}

SEC("kretprobe/_raw_spin_unlock_irqrestore")
int kretprobe_spin_unlock(struct pt_regs *ctx) {
    u64 lock_addr = PT_REGS_PARM1(ctx);
    u64 *start_ts = bpf_map_lookup_elem(&start_times, &lock_addr);

    if (start_ts) {
        u64 duration_ns = bpf_ktime_get_ns() - *start_ts;

        struct lock_event event = {};
        event.pid = bpf_get_current_pid_tgid() >> 32;
        bpf_get_current_comm(&event.comm, sizeof(event.comm));
        event.lock_addr = lock_addr;
        event.duration_ns = duration_ns;
        event.type = 1; // Released

        bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU, &event, sizeof(event));
        bpf_map_delete_elem(&start_times, &lock_addr);
    }
    return 0;
}
"""

# 定义与内核中lock_event结构体对应的Python结构体
class LockEvent(ct.Structure):
    _fields_ = [
        ("pid", ct.c_uint),
        ("comm", ct.c_char * 16), # TASK_COMM_LEN is 16
        ("lock_addr", ct.c_ulonglong),
        ("duration_ns", ct.c_ulonglong),
        ("type", ct.c_ubyte),
    ]

# 定义事件类型常量
EVENT_TYPE_CONTENDED = 2
EVENT_TYPE_RELEASED = 1

def print_event(cpu, data, size):
    event = ct.cast(data, ct.POINTER(LockEvent)).contents
    event_type_str = ""
    if event.type == EVENT_TYPE_CONTENDED:
        event_type_str = "CONTENDED"
        print(f"[{time.strftime('%H:%M:%S')}] PID {event.pid:<7} COMM {event.comm.decode():<16} LOCK_ADDR {event.lock_addr:#x} {event_type_str:<10} DURATION {event.duration_ns / 1000:.2f} us")
    elif event.type == EVENT_TYPE_RELEASED:
        event_type_str = "RELEASED"
        # We only print released events if they are long enough to be interesting
        if event.duration_ns > 100000: # filter for durations > 100us
            print(f"[{time.strftime('%H:%M:%S')}] PID {event.pid:<7} COMM {event.comm.decode():<16} LOCK_ADDR {event.lock_addr:#x} {event_type_str:<10} DURATION {event.duration_ns / 1000:.2f} us")

# 加载eBPF程序
b = BPF(text=bpf_text)

print("Tracing kernel spinlock events... Hit Ctrl-C to end.")

# 绑定perf buffer回调函数
b["events"].open_perf_buffer(print_event)

while True:
    try:
        b.perf_buffer_poll()
    except KeyboardInterrupt:
        sys.exit(0)

运行脚本：

sudo python3 custom_lock_tracer.py

当 file_writer 进程运行时，你将看到类似如下的输出：

Tracing kernel spinlock events... Hit Ctrl-C to end.
[14:30:05] PID 12345   COMM file_writer      LOCK_ADDR 0xffff8881001e0d70 CONTENDED  DURATION 15.34 us
[14:30:05] PID 12346   COMM file_writer      LOCK_ADDR 0xffff8881001e0d70 CONTENDED  DURATION 20.11 us
[14:30:05] PID 12347   COMM file_writer      LOCK_ADDR 0xffff8881001e0d70 CONTENDED  DURATION 18.70 us
[14:30:05] PID 12345   COMM file_writer      LOCK_ADDR 0xffff8881001e0d70 RELEASED   DURATION 120.50 us
[14:30:05] PID 12348   COMM file_writer      LOCK_ADDR 0xffff8881001e0d70 CONTENDED  DURATION 10.99 us
[14:30:05] PID 12346   COMM file_writer      LOCK_ADDR 0xffff8881001e0d70 RELEASED   DURATION 95.20 us
...

脚本解释：

1. 内核部分 (bpf_text):

   • start_times：一个哈希映射，用于存储每个 lock_addr 对应的 __raw_spin_lock_irqsave 调用开始时间戳。
   • lock_event：一个结构体，定义了我们希望从内核发送到用户空间的数据格式，包括PID、进程名、锁地址、持续时间、事件类型。
   • events：一个 perf_event_array 映射，用于将 lock_event 实例发送到用户空间。
   • kprobe_spin_lock：挂钩到 __raw_spin_lock_irqsave 函数入口。当它被调用时，我们检查 start_times 中是否已存在该锁地址。如果存在，说明锁已经被其他CPU持有，当前CPU正在尝试获取，此时我们发送一个 CONTENDED 事件。然后，无论如何，我们都更新或插入当前锁的获取时间。
   • kretprobe_spin_unlock：挂钩到 _raw_spin_unlock_irqrestore 函数返回。当锁被释放时，我们从 start_times 中查找对应的开始时间，计算锁的持有时间，发送一个 RELEASED 事件，并从 start_times 中删除该条目。

2. 用户态部分 (Python):

   • 使用 bcc.BPF(text=bpf_text) 加载并编译eBPF程序。
   • 定义 LockEvent Python类，与内核中的 struct lock_event 对应，以便正确解析数据。
   • print_event 是一个回调函数，当内核发送事件时被调用。它解析事件数据并打印。我们过滤了短暂的 RELEASED 事件，只显示持续时间较长的，以突出潜在的瓶颈。
   • b["events"].open_perf_buffer(print_event) 注册回调函数。
   • 主循环 b.perf_buffer_poll() 不断从perf buffer中读取事件。

这个自定义脚本提供了对自旋锁争用更精确的实时洞察。你可以根据需要修改 bpf_text 来跟踪其他类型的内核锁（如 mutex_lock, rwsem_down_read_failed 等），或者收集更多的上下文信息（如调用栈）。

结合 uprobe 和 kprobe 追踪

为了更深入地理解内核锁争用与用户态C++代码的关系，我们可以结合 uprobe 追踪C++应用程序中的特定函数，以及 kprobe 追踪内核锁。

例如，我们可以用 uprobe 追踪 file_writer 进程中的 write_to_file 函数。

// BPF C code to trace user-space write_to_file
SEC("uprobe/./file_writer:write_to_file")
int probe_write_to_file(struct pt_regs *ctx) {
    u32 pid = bpf_get_current_pid_tgid() >> 32;
    char comm[TASK_COMM_LEN];
    bpf_get_current_comm(&comm, sizeof(comm));
    bpf_trace_printk("User: PID %d, COMM %s entered write_to_file\n", pid, comm);
    return 0;
}

将这段 bpf_text 添加到我们的Python脚本中，并将其挂载到 ./file_writer 可执行文件中的 write_to_file 符号上。这样，我们就能在每次 write_to_file 被调用时，得到一个用户态的跟踪点，然后结合内核锁的跟踪，就能更清晰地看到用户态行为如何映射到内核争用。

生产环境下的考量

在生产环境中部署和使用 perf 和 eBPF 进行监控，需要考虑以下几点：

1. 性能开销:

   • perf 采样: 通常开销较低（1-5% CPU），适合长期运行。采样频率过高会增加开销。
   • eBPF 追踪: eBPF 程序非常高效，通常开销极低（0.1-1% CPU）。但过度频繁的 perf_event_output 或复杂的计算仍可能增加开销。
   • 原则: 始终在非生产环境进行充分测试，并从小范围开始部署。

2. 权限:

   • perf 和 eBPF 通常需要 CAP_SYS_ADMIN 或 CAP_PERFMON 权限才能运行。在生产环境中，应谨慎授权。
   • 可以为特定用户或组配置 kernel.perf_event_paranoid 和 kernel.kptr_restrict sysctls 来限制 perf 和 eBPF 的使用，以增强安全性。

3. 符号解析:

   • 为了使 perf report 和 eBPF 跟踪的调用栈可读，需要有内核和用户态程序的调试符号。
   • 内核符号: 确保 /proc/kallsyms 可读，通常是默认开启的。
   • 用户态符号: 编译C++程序时，使用 -g 选项包含调试信息。在生产环境中，通常会部署剥离了调试符号的二进制文件。可以保留调试符号在单独的文件中（debuginfo 包），并在需要分析时加载。

4. 自动化和集成:

   • 手动运行工具进行分析效率低下。应考虑将 eBPF 监控集成到现有的监控系统（如Prometheus + Grafana）。
   • eBPF 程序可以将指标数据存储在 BPF_MAP_TYPE_HASH 中，用户态程序可以定期读取这些映射，然后推送给Prometheus。
   • 可以使用 bpftrace 这样更高级的语言来快速编写一次性脚本或简单的自动化脚本。

5. 数据聚合和告警:

   • 实时流式输出固然有用，但对于长期趋势和异常检测，需要聚合数据。
   • 例如，可以计算每秒的锁争用事件数、平均等待时间、最大等待时间等指标。
   • 设置合理的阈值，当这些指标超过阈值时触发告警。

6. 可观测性平台: 许多现代可观测性平台（如Datadog, New Relic, Pixie）已经集成了 eBPF 功能，提供了开箱即用的内核级监控。如果条件允许，利用这些平台可以大大简化部署和分析工作。

洞察内核，优化未来

通过 perf 和 eBPF，我们获得了前所未有的能力，能够深入Linux内核，实时洞察C++应用程序与操作系统之间的交互细节，特别是内核锁争用这一隐形杀手。perf 提供了全面的性能采样和热点分析能力，是快速定位问题的利器；而 eBPF 则以其在内核中的可编程性，赋予了我们定制化、低开销、高精度的实时跟踪和测量能力。掌握这些工具，将使您在优化高性能C++应用程序的道路上如虎添翼，能够更自信地应对复杂的生产环境挑战。