Hacker News 中文摘要

RSS订阅

如何分析eBPF代码？ -- How Do I Profile eBPF Code?

原文链接 | HN讨论 | 2026-07-29 06:24:49

文章摘要

本文介绍了如何对eBPF代码进行性能分析，以文件打开操作为例，通过编写一个简单的C测试程序来测量eBPF钩子引入的性能开销，并识别潜在瓶颈。

文章总结

好的，这是根据您的要求，对原文进行中文重述和精简后的版本：

如何分析 eBPF 代码的性能

当我们运行或编写 eBPF 代码时，需要衡量其性能影响。本文将以测量文件打开操作的性能为例，演示具体方法。

我们的目标是测量 eBPF 文件打开钩子（hook）引入的性能开销。为此，我们设计了一个简单的 C 语言测试程序，用于测量文件打开的性能。该程序的核心逻辑是：在缓存已预热的情况下，反复打开同一个文件，以最小化文件系统和磁盘 I/O 的干扰，从而识别出性能的 p50/p99 值。代码直接调用 syscall(SYS_openat, ...) 而非 libc 的 openat() 封装，并丢弃前 10% 的结果作为预热期。

环境设置

为了在分析 eBPF 代码时，perf 工具能够解析符号（而非显示未知地址），需要执行以下命令，启用 JIT 并暴露 JIT 编译后的 BPF 符号：

sudo sysctl -w net.core.bpf_jit_enable=1 sudo sysctl -w net.core.bpf_jit_kallsyms=1

之后，可以运行 eBPF 代码，并用 bpftool 和 rg 命令检查符号是否已出现在 /proc/kallsyms 中。

性能测量

首先，在不运行 eBPF 代码的情况下进行测量，作为基线。使用上述 C 程序打开 /etc/hostname 文件 10 万次，并将结果输出到文件，用于计算 p50/p99。命令如下：

sudo taskset -c 3 chrt -f 99 ./bench /etc/hostname 100000 > /tmp/samples.txt

其中，taskset -c 3 将程序绑定到 CPU 3，chrt -f 99 赋予其极高的 CPU 优先级。

接着，运行 eBPF 代码，并使用 perf record 进行采样：

sudo $PERF record -g --call-graph fp -e cycles:k -F 997 -o ~/perf.data -- taskset -c 3 chrt -f 99 ./bench /etc/hostname 200000 > /tmp/samples.txt

参数说明：-g 记录调用栈，--call-graph fp 使用帧指针展开栈，-e cycles:k 仅采样内核模式下的 CPU 周期，-F 997 设置每秒 997 次采样。

采样完成后，使用 perf report 生成报告：

sudo "$PERF" report -i ~/perf.data --stdio --sort comm,dso,symbol > perf.txt

结果分析

从生成的 perf.txt 输出（或火焰图）中，可以清晰地看到性能瓶颈所在。例如，示例结果显示，大量时间消耗在 bpf_lsm_file_open 及其尾调用上，这表明该钩子位于热路径上，任何微小的优化都能显著提升系统性能。

本文重点在于介绍性能分析方法，而非具体结果。您实际观察到的开销将完全取决于 eBPF 钩子所执行的操作。

通过上述方法，我们可以明确识别 eBPF 代码的性能影响，并精准定位需要优化的地方，例如缓存某些数据或改进算法。

评论总结

根据评论内容，总结如下：

主要观点与论据：

  1. 性能分析资源补充（作者okzgn，评分无）：提供了三篇关于eBPF性能的论文和文章，分别分析LSM/tracing钩子开销、eBPF映射性能（如htabmaphash瓶颈）以及网络eBPF性能。关键引用：

    • "Analyzes the overhead introduced by LSM/tracing hooks on the kernel"
    • "Useful context for the htabmaphash bottleneck shown in the perf report"

  2. TLB缺失问题（作者jeffbee，评分无）：强调除CPU周期外，还应关注TLB缺失率。指出eBPF映射可能污染虚拟地址转换缓存，实际案例中90%的周期时间归因于页表遍历，并对应用程序产生严重副作用。关键引用：

    • "eBPF isn't magical and any maps of significant size may pollute your virtual address translation caches"
    • "over 90% of the cycle time was attributable to page table walks"

  3. 工具推荐（作者tanelpoder，评分无）：介绍自研工具"brr"（eBPF Runtime Reporter and Profiler），可显示类似bpftop的摘要，并支持深入查看eBPF程序源码行及内核代码活动，以全面分析延迟。关键引用：

    • "displays a bpftop-like eBPF program summary, but you can also zoom into any program to see its source code lines"
    • "profile the eBPF program activity and any kernel code activity called/caused by the eBPF program"

平衡性说明： 评论整体聚焦于eBPF性能优化，无对立观点。okzgn提供资源，jeebee指出TLB问题，tanelpoder推荐工具，三者互补。