如何用eBPF在香港裸金属服务器上进行高频系统调用追踪与性能剖析？

发布人：Minchunlin 发布时间：2025-07-30 18:03 阅读量：598

几个月前，我在香港运营一组面向交易型业务的裸金属服务器集群。这些机器几乎每秒处理成千上万次系统调用，承载着数据库请求、网络转发和秒级报表合成。某天下午，某台主机的系统负载突然异常升高，top 和 sar 给出的信息太粗糙，perf 又因为 overhead 过高无法用于生产。这种情况下，我意识到是时候祭出内核态的利器——eBPF。

本文将从实战出发，介绍我如何在香港裸金属环境中用 eBPF 实现对高频系统调用的追踪与性能剖析。我们将涉及 eBPF 的核心概念、程序设计、工具选择、踩坑经验以及如何在不中断业务的前提下完成系统级分析。

一、环境背景与需求分析

1.1 裸金属服务器环境概况

地域：香港数据中心（低延迟网络）
操作系统：Ubuntu 22.04 LTS（内核 5.15.0-91）
CPU架构：Intel Xeon Gold 6338
应用类型：自研交易撮合引擎 + PostgreSQL + gRPC 微服务集群
场景特点：大量短连接、IO密集型、系统调用频繁

1.2 问题表现

单台机器 CPU Idle 降至 10% 以下
load average 居高不下，但进程 CPU 使用率不高
suspect syscall 频繁但无法定量识别热点

目标很明确：

追踪所有频繁系统调用的分布情况，并定位导致性能瓶颈的具体函数、内核路径或用户栈调用链。

二、为何选择 eBPF 而不是 perf / strace？

strace：附加式，适用于调试，不适合高频生产追踪，overhead 高
perf：采样能力强但缺乏灵活性，频繁 attach 有风险
eBPF：轻量、事件驱动、可编程，支持内核态和用户态观测

此外，eBPF 支持非侵入式 attach 到 tracepoint、kprobe、uprobe，可以在不中断业务的情况下插桩并收集粒度极细的数据。

三、eBPF 实战部署步骤

3.1 安装和工具准备

在香港裸金属服务器上，我使用以下工具组合：

bcc：Python + C 编写 eBPF 程序的工具链，快速上手
bpftrace：DTrace 式语法，适合一键临时分析
bpftool：官方命令行调试工具
libbpf + CO-RE: 高性能生产级部署方式

# 安装 bcc 和 bpftrace
sudo apt-get install bpfcc-tools linux-headers-$(uname -r) bpftrace

四、追踪高频系统调用：案例实战

4.1 使用 bpftrace 快速热插桩 syscall

sudo bpftrace -e 'tracepoint:syscalls:sys_enter_* { @[probe] = count(); }'

此命令会在所有系统调用进入点收集调用频率：

输出（数秒后）：

@sys_enter_sendto: 1856453
@sys_enter_recvfrom: 1603789
@sys_enter_epoll_wait: 1219032
@sys_enter_openat: 21984

我们发现 sendto, recvfrom, epoll_wait 是调用频次最高的函数。它们均与网络IO密切相关。

4.2 深入分析单个系统调用的延迟分布

我们使用 bcc 中的工具 runqlat 进行调度延迟分析：

sudo /usr/share/bcc/tools/runqlat -m 5

结果显示某些短任务被频繁抢占，影响整体性能。

进一步使用 execsnoop 和 opensnoop 查看进程行为：

sudo /usr/share/bcc/tools/execsnoop
sudo /usr/share/bcc/tools/opensnoop

但发现没有频繁进程创建或文件打开。

因此将目标聚焦到 socket 层。

五、编写定制化 eBPF 程序

我们使用 Python + BCC 编写自定义 syscall latency 追踪器。

5.1 程序核心逻辑（精简版）

from bcc import BPF
from time import sleep

bpf_text = """
#include <uapi/linux/ptrace.h>
BPF_HASH(start, u64, u64);
BPF_HISTOGRAM(dist);

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

int trace_return(struct pt_regs *ctx) {
    u64 ts = bpf_ktime_get_ns();
    u64 tid = bpf_get_current_pid_tgid();
    u64 *tsp = start.lookup(&tid);
    if (tsp != 0) {
        u64 delta = ts - *tsp;
        dist.increment(bpf_log2l(delta / 1000)); // μs
        start.delete(&tid);
    }
    return 0;
}
"""

b = BPF(text=bpf_text)
b.attach_kprobe(event="__x64_sys_sendto", fn_name="trace_entry")
b.attach_kretprobe(event="__x64_sys_sendto", fn_name="trace_return")

print("Tracing... Hit Ctrl-C to end.")
try:
    sleep(10)
except KeyboardInterrupt:
    pass

b["dist"].print_log2_hist("latency (us)")

六、结果分析与优化建议

6.1 延迟分布结果

latency (us)     : count
     0 -> 1      : 183049
     2 -> 4      : 914829
     8 -> 16     : 582193
    32 -> 64     : 12982
   256 -> 512    : 3041

绝大多数延迟集中在 < 16us：表明调用本身并不慢

长尾 (>256us) 占比小但存在，需关注

6.2 优化方向建议