Linux 性能诊断实战：从 perf 到 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 记录上下文切换的调用栈，确认是否为频繁的锁竞争或调度延迟。 ...