Linux 性能调优与追踪完整篇：ftrace、perf、eBPF从采样到落地验证

CPU 被打满却说不清热点、延迟尖刺只能「重启试一下」、上线后回归全靠猜——缺的不是参数列表而是可复现的观测路径从 tracepoint/kprobe 到采样火焰图再到改参与回归对比。本文把 ftrace、perf_event、eBPF/bpftrace、常见调优开关与排障顺序合成一篇闭环。源码锚点路径作用kernel/trace/ftrace.cftrace 核心、function tracerkernel/trace/trace.ctracefs 环形缓冲与输出include/linux/ftrace.hftrace APIkernel/events/core.cperf_event子系统kernel/kprobes.ckprobe 动态插桩kernel/bpf/eBPF 验证器、地图、运行时kernel/trace/bpf_trace.cBPF 与 tracing 衔接fs/tracefs//debugfs用户态控制面挂载点因发行版而异tools/perf/用户态 perf 工具Documentation/trace/、Documentation/bpf/官方追踪与 BPF 文档ftrace 控制面示意# 通常需要 root路径可能是 /sys/kernel/tracingmount|greptracefscd/sys/kernel/tracingechofunctioncurrent_tracerechodo_sys_openat2set_ftrace_filter# 示例符号以本机为准echo1tracing_oncattrace|headecho0tracing_onperf 采样骨架perf record-F99-g-- ./app perf report# 或系统范围perftopperf record-a-g--sleep10调用链观测数据从内核到用户态静态动态函数PMU 采样可编程感兴趣事件观测手段tracepointkprobe / ftrace filterperf_eventeBPF 程序ring buffer / perf mmapBPF map / ringbuf用户态工具读取报告 / 火焰图 / 指标调优闭环分层验证假设与改动观测定义问题延迟? CPU? IO? 唤醒?建立 baselineperf / top / iostatftrace / trace-cmdbpftrace / BCC调度/内存/IO/驱动参数代码热点修复同负载复测回滚开关重点知识1. 先定性再选工具症状先看深挖CPU 高perf top/record -g符号、锁、软中断延迟尖刺cyclictest、调度/中断追踪irqsoff/preemptirqsoff、唤醒链IO 等iostat、perfblock 事件电梯、队列深度、FS 回写内存/proc/meminfo、psireclaim、oom、cgroup 限制没有 baseline同负载下的延迟/CPU/带宽数字就改sysctl属于盲调。2. ftrace低成本看清调用与关闭抢占function / function_graph看谁调用谁、耗时轮廓。irqsoff / preemptoff关中断/关抢占过久驱动里常见。sched / wakeup任务为何睡、被谁唤醒。trace-cmd record-esched:sched_switch-esched:sched_wakeupsleep5trace-cmd report|head注意过滤不当时开销与 trace 体积会爆生产先短时、窄 filter。3. perfPMU 采样与火焰图perf_event把硬件计数器/软件事件接到统一接口perf record采样调用栈适合「CPU 花在哪」。# 权限相关sysctlkernel.perf_event_paranoid# 常见cache-misses、cycles、page-faultsperfstat-ecycles,cache-misses,page-faults -- ./app解读要点采样有偏差内联/缺符号会「糊」先保证 vmlinux/debuginfod 或至少 kallsyms 可读。4. eBPF验证后可编程观测流程编写或 bpftrace 一行→verifier保证安全 → 加载 → 挂到 kprobe/tracepoint/XDP 等 → map/ringbuf 汇总。# 示例统计 syscall 次数语法随 bpftrace 版本微调bpftrace-etracepoint:raw_syscalls:sys_enter { [comm] count(); }约束无 verifier 通过则无法加载——这是特性不是障碍生产控制 attach 范围与采样率避免自扰动权限通常需要CAP_BPF/CAP_PERFMON或 root视内核与发行版。5. kprobe 与开销意识kprobe 可动态插到几乎任意内核函数但热路径高频命中会显著扰动部分函数不可探测或随版本改名优先用稳定tracepointkprobe 作补充。6. 配置与安全# 追踪文件系统mount-ttracefs tracefs /sys/kernel/tracing# BPF 文件系统部分工具需要mount-tbpf bpf /sys/fs/bpf项说明kernel.perf_event_paranoid控制非特权 perf 能力debugfs/tracefs 权限避免无关用户读内核地址信息生产追踪限时、限事件、有回滚7. 从观测到改参几类高频旋钮先测后改领域示例入口说明调度schedutil、CPU 亲和、nice/cgroup cpu先确认是否真 CPU 饱和内存vm.swappiness、vfs_cache_pressure、cgroup 限制配合 PSI/meminfo网络somaxconn、队列、NAPI/中断开销先ss/perf再改块 IO调度器、队列深度、ionice先分清读/写/刷新驱动线程化 IRQ、合并工作、避免关中断过久用irqsoff验证原则一次只改一类变量保留开关与回滚命令。容器/ cgroup 场景下宿主机sysctl与容器限额要分开看。8. 常见坑坑结果处理无符号表火焰图全是地址安装 debug 包 / 带 vmlinux同时开太多 tracer机器变慢、数据失真单次一种目的只调参不复测「好像好了」固定负载脚本对比把平均当尾延迟P99 仍炸看直方图/百分位在生产长期开 function tracer吞吐断崖限时、窄 filter、事后关闭Checklist调优前有书面 baseline负载描述 关键指标能说明 ftrace / perf / eBPF 各自擅长的问题类型会用perf record -greport定位用户/内核热点会在 tracefs 上做一次窄过滤的 function 追踪并关闭优先选用 tracepoint明白 kprobe 的开销与版本风险知道perf_event_paranoid与 tracefs 挂载对工具的影响每次改动可回滚并用同一负载复测验证小结内核已经把观测做成可组合管线事件源 → 缓冲/映射 → 用户态分析。调优的设计意图不是堆参数而是用 ftrace/perf/eBPF 把假设证伪或证实。顺序固定为定性 → 选工具 → 短时窄范围采集 → 改一处 → 对比 baseline。