EBPF

背景与问题界定 某电商平台大促期间，核心下单接口的 P99 延迟从 200ms 飙升到 3.2s，CPU 饥渴地跑在 95% 但业务层看不出任何明显瓶颈。线上排查时，top 和 htop 只能看到进程级 CPU 使用率，无法定位到具体函数或内核调用路径。传统 strace 在生产环境会带来 10 倍以上的性能开销，无法直接使用。这暴露了一个典型问题：现代高并发系统中，性能瓶颈往往埋藏在系统调用层、内核协议栈或内存分配的微妙竞争点上，需要一套低开销、“显微镜级"的诊断工具组合。 目标拆解与工程约束 零入侵采样：诊断工具不能对生产业务进程造成显著的性能影响，采样开销必须控制在 1% CPU 以内，不能让诊断本身成为新的性能瓶颈。 全栈追踪能力：工具链必须覆盖从应用层函数、库调用、系统调用到内核函数、硬件 PMU 事件的全栈追踪，能在一个时间线上串联用户态和内核态的执行路径。 动态插桩：不能在业务代码中预先埋点，必须支持对运行中的进程进行动态插桩，且插桩点和追踪逻辑可以在不重启进程的情况下热插拔和调整。 安全与权限约束：生产环境上使用 eBPF 需要保证内核版本 >= 4.19（基础功能）或 >= 5.4（CO-RE 支持），同时需要控制 BPF 程序的复杂度（指令数 <= 4096），防止 BPF JIT 引发内核 panic。 方案设计 故障排查采用分层诊断策略。第一层使用 perf 进行快速的 CPU 热点定位，通过 perf top -p <pid> 查看进程级别热点函数，利用 CPU 硬件 PMU 中的 cycles 事件采样统计函数调用频率。当 perf 显示热点集中在内核态时（如 _raw_spin_lock 或 tcp_v4_rcv），使用 perf record -e sched:sched_switch -g 记录上下文切换的调用栈，确认是否为频繁的锁竞争或调度延迟。 ...

为什么要持续 Profiling 离线抓火焰图只能解释“当下问题”，无法覆盖版本演进中的渐进回归。持续 profiling 能提供趋势视角。 落地关键 采样频率按服务等级分层，避免全局高频。 只保留聚合后的符号栈，降低存储压力。 结合版本号维度做回归对比。 噪声治理 排除短命批处理进程。 对 JIT 语言补齐符号映射。 过滤启动期冷缓存阶段样本。 常见风险 盲目提高采样率导致 CPU 额外开销。 内核版本不一致引发采样偏差。 只看 Top 函数，忽视调用链变化。 小结 持续 profiling 不是“多收集”，而是“低扰动、可对比、可解释”的长期性能体检体系。