性能剖析与追踪工具（perf/ftrace/bpftrace/USDT）

• perf record -g
• FlameGraph
• on-CPU profiling

perf record -g 采样调用栈（-g 记录栈回溯），生成 CPU 占用分布；FlameGraph（火焰图）把栈采样可视化：宽度代表 CPU 时间占比、深度代表调用栈深度，直观展示"CPU 时间花在哪"（热点函数与调用链）。on-CPU profiling：分析 CPU 上的时间消耗（哪些函数/路径占 CPU），用于优化 CPU 热点。工程价值：火焰图快速定位 CPU 热点（宽项）、识别调用链、比较前后版本优化效果。流程：perf record -g -F 频率采样 → perf script 导出 → flamegraph.pl 生成火焰图。注意：只覆盖 on-CPU 时间，off-CPU（阻塞）需另分析。

perf record -g 采栈、FlameGraph 可视化（宽=CPU 时间、深=调用栈）。on-CPU profiling 定位 CPU 热点与调用链。

• ftrace function_graph
• off-CPU
• tracepoint

ftrace function_graph 是内核函数调用追踪器，记录函数调用图（进入/退出、耗时），可显示内核函数执行时间与调用链。off-CPU 分析：分析线程阻塞/等待的时间（非 CPU 上执行），如阻塞在锁、I/O、调度；function_graph 可追踪函数调用耗时，识别慢路径（如内核函数内阻塞）。自定义 tracepoint：内核的 tracepoint 是静态埋点（可开关），配合 ftrace 可追踪特定子系统事件。工程价值：function_graph 用于定位内核函数耗时与调用链，tracepoint 用于事件流追踪，两者结合分析 off-CPU 阻塞与内核 hot path。

function_graph 追踪内核函数调用图与耗时，tracepoint 是静态可开关埋点。用于 off-CPU 与内核性能分析。

• BPF ringbuf
• perf event buffer
• 内存与唤醒

perf event buffer（perf_event_open）是 per-CPU 的环形缓冲，但要求每 CPU 分别提交/消费，且无共享内存（数据需经系统调用读取），高负载下 per-CPU 数据可能丢失（overrun）。BPF ringbuf（BPF_MAP_TYPE_RINGBUF）改进：共享内存（用户态与内核共享同一环形缓冲，无需拷贝）、减少 per-CPU 数据丢失（单共享缓冲可吸收 CPU 间负载不均，虚拟化/热插拔友好）、高效唤醒（支持 reserve/commit 两阶段，减少锁）；BPF ringbuf 支持 multi-producer/multi-consumer。适用：perf buffer 适合结构简单、单 CPU 场景；ringbuf 适合高吞吐、多核、需要低丢失与共享内存的场景。

BPF ringbuf 共享内存、单缓冲吸收负载不均、reserve/commit 高效唤醒，优于 per-CPU perf buffer。高吞吐用 ringbuf。

• Conprof
• cycle-based profiling
• overhead 取舍

Conprof 是开源的连续剖析（continuous profiling）工具（后并入 Parca 项目），其 cycle-based 采样用硬件时钟周期（PMU cycles）计数进行采样，开销低、精确度高。工程取舍：优点——低开销（硬件采样，优于定时采样）、可辨识 CPU 周期计量（更贴近真实 CPU 时间）、内核级采样支持（用户态与内核态都可剖析）；代价——需硬件 PMU 支持、采样精度受周期与采样率影响。相比定时采样（perf 的 itimer），cycle-based 更贴近实际 CPU 消耗（不受时钟中断频率影响）。工程上：低开销持续剖析用 Conprof（cycle-based），适合生产环境 Always-on profiling。

Conprof 用硬件周期采样，低开销、精确，适合生产持续剖析。需硬件 PMU 支持，是定时采样与周期采样的权衡。

• bpftrace
• tracepoint
• sys_enter_openat

该 bpftrace 脚本追踪 openat 系统调用：tracepoint:syscalls:sys_enter_openat 是内核预设的 tracepoint（进入 openat 时触发），{ printf("%s %s\n", comm, str(arg0)); } 是动作——打印 comm（进程名）与 arg0（openat 的第一个参数，即路径名，str() 把指针转为字符串）。printf 的 %s 对应 comm 与 str(arg0)。工程价值：一行脚本即可追踪所有 openat 调用（谁打开哪个文件），用于文件访问监控、I/O 分析、安全审计。bpftrace 基于 eBPF，内核静态 tracepoint 开销低、无需重编译。可扩展参数：arg1 是 flags、arg2 是 mode。

该脚本在 openat 进入时打印进程名与路径名（arg0 经 str() 转字符串）。一行追踪文件访问，静态 tracepoint 低开销。

• USDT
• static probes
• dtrace-style

USDT（User Statically-Defined Tracing，用户静态定义追踪）在源码中预埋静态探针（程序员在关键位置定义追踪点），编译后保留为可激活的探针。dtrace-style static probes：类似 DTrace 的 probe 定义（provider:module:function:name），在进程内提供稳定、可预测的探测点。工程价值：提供稳定探测点（不随代码变化失效）、可动态启用（无需重启/重编译，运行时激活）、开销低（未启用时几乎零开销）。与动态 uprobe 相比，USDT 是源码级稳定探针，不会因符号变化而失效。工具支持：bpftrace、bcc、perf 可 attach 到 USDT 探针。

USDT 是源码预埋的静态探针，稳定、可动态启用、低开销。dtrace-style 提供稳定探测点，优于动态 uprobe。

• Pyroscope
• flamegraph aggregation
• 持续剖析

Pyroscope 是 Rust 开源持续剖析（continuous profiling）平台，采集并聚合各类应用的调用栈，生成火焰图（flamegraph aggregation 聚合多个采样/实例的调用栈）。工程价值：持续、低开销地剖析生产应用；聚合多实例/多服务的调用栈，统一展示 CPU/内存/分配的火焰图；跨语言（Go、Java、Python、Rust 等）支持；与 Prometheus 集成对比剖析指标。Rust 实现性能好、内存占用低，适合服务端持续剖析。相比单次 perf 火焰图，Pyroscope 提供持续聚合多实例的视角，便于对比版本与定位长期热点。

Pyroscope 是 Rust 持续剖析平台，聚合多实例调用栈生成火焰图。跨语言、低开销，对比版本定位长期热点。

• uprobes
• user-space tracing
• bpftrace/bcc

uprobes（用户态探针）可在用户程序任意函数入口/返回处动态插桩（动态函数追踪），bpftrace/bcc 用 uprobe 追踪用户态函数调用（参数、返回值、耗时）。与 USDT 协同：USDT 是源码预埋的静态探针（稳定、语义明确），uprobe 是动态探针（无需源码埋点、可探测任意函数，但依赖符号/地址，可能随版本变化失效）。工程价值：uprobe 用于无从埋点或动态追踪用户态函数（如库函数、第三方代码），USDT 用于预埋的稳定探针；两者结合——有 USDT 用 USDT（稳定），无则用 uprobe（动态）。

uprobe 动态追踪用户态任意函数，USDT 是源码预埋静态探针。uprobe 灵活但依赖符号易失效，USDT 稳定。

• Parca
• eBPF profiling
• 持续剖析

Parca 是开源 eBPF-based 持续剖析（continuous profiling）工具，用 eBPF 在内核采样调用栈，无需改动应用（无侵入、低开销）。工程价值：无侵入（eBPF 采样）、低开销（适合生产）、支持多种语言（通过 eBPF 栈采样 + 符号还原）、可聚合多节点/多实例。相比需 agent 注入或 SDK 的剖析工具，Parca 用 eBPF 提供"零侵入"的持续剖析，适合大规模生产环境。功能：采样栈、火焰图展示、跨实例聚合、与 Prometheus 集成。工程上：Parca 用于生产环境持续剖析，eBPF 采样开销低、无需重编译应用。

Parca 用 eBPF 在内核采样栈，无侵入、低开销，适合生产持续剖析。eBPF 采样无需改动应用。

• bpftrace @hist
• @lquantize
• latency histogram

bpftrace 的 @hist（直方图）把值归入对数桶（log2 分桶，覆盖大范围），@lquantize（线性直方图）按固定间隔分桶（线性，适合观察特定小范围分布）。两者都用于 latency histogram（延迟直方图）：@hist 适合宽范围延迟（μs 到 ms 到 s），@lquantize 适合细粒度观察特定区间（如 0-100ms 每 10ms 一桶）。工程价值：用 @hist/@lquantize 汇总延迟分布（如 syscall 延迟、函数耗时），直观看出 P50/P99 分布与异常尖峰，比平均值更能暴露长尾。配合 tracepoint/kprobe 测量入口到出口延迟。

@hist 对数分桶（宽范围）、@lquantize 线性分桶（细粒度）。用于延迟直方图，暴露长尾与分布。

• perf 与 ftrace 联合
• tracepoint 触发
• latency 分析

perf 与 ftrace 联合：用 perf 触发/定位事件（如某 tracepoint 命中、热点函数），再用 ftrace 深入追踪该路径的 latency（延迟）。工程价值：perf 擅长全局采样与事件计数（定位热点、触发 tracepoint），ftrace 擅长函数调用图与延迟分析（function_graph 显示函数耗时、阻塞点）。联合流程：perf 定位问题（哪个 tracepoint/函数）、ftrace 放大该路径（function_graph 追踪该函数调用链与耗时）→ 定位延迟根因。互补：perf 给"全局视角"，ftrace 给"单点深度"，两者结合覆盖 on-CPU 与 off-CPU 延迟。

perf 全局定位事件/热点，ftrace 深入追踪函数调用与延迟。两者互补：perf 找问题、ftrace 放大路径定位延迟。

• 实时信号
• systemtap/perf probe
• 信号追踪

实时信号（SIGRTMIN+，具排队与优先级）在 systemtap / perf probe 中可用于追踪信号投递与处理：通过 probe 监控信号发送（如 kill/sigqueue）与接收（信号处理），分析信号事件流。工程应用：追踪实时信号（如 SIGRTMIN+n 用于线程间通信、通知）的发送/接收时机与数据（sigqueue 的 sigval），诊断信号丢失、延迟、死锁；systemtap/perf probe 可 probe 到信号相关内核函数（如 send_signal、do_signal）或用户态信号处理器。实时信号排队且带数据，perf/systemtap 可观测其投递与处理。工程上：用 probe 追踪信号链路，定位信号通知延迟或遗漏。

实时信号排队且带数据，systemtap/perf probe 可追踪信号发送/接收与处理，诊断信号丢失与延迟。

• USDT probe
• libc/OpenSSL
• overlap guard

libc、OpenSSL 等库内置了 USDT probe（静态探针），如 libc 的 malloc/free 探针、OpenSSL 的 TLS 握手/加密探针，供外部追踪工具（bpftrace、perf、DTrace）激活。工程价值：无需改动应用即可追踪库内关键路径（内存分配、TLS 握手），探针稳定、语义明确。overlap guard（重叠防护）：探针定义（ELF 中的 .note.stapsdt 段）与代码地址可能重叠或编译器优化消除，需 guard 机制确保探针记录有效、避免访问失效地址；半激活探针（dormant）在未启用时零开销。工程上：用库内 USDT 探针追踪标准库关键路径，理解探针激活机制避免误用。

libc/OpenSSL 内置 USDT 探针，可追踪库内关键路径。overlap guard 保证探针地址有效，未启用零开销。

• Datadog Continuous Profiler
• AL2 hardware profiler
• 生产剖析

Datadog Continuous Profiler 是 ADM（Application Performance Monitoring）的持续剖析组件，持续采样生产应用调用栈（CPU、内存、分配），用于定位性能热点。AL2 hardware profiler 指在 Amazon Linux 2 上利用硬件性能计数器（PMU）进行低开销采样剖析。工程价值：持续（Always-on）剖析生产环境，低开销（硬件采样）、跨实例聚合、与 trace/metric 关联（剖析栈与请求链路关联），暴露 CPU/内存/分配热点。相比手动 perf，Datadog 提供托管、自动、可检索的持续剖析。工程上：通过硬件采样降低开销，持续追踪生产性能回归。

Datadog Continuous Profiler 持续采样生产调用栈，AL2 硬件 profiler 用 PMU 低开销采样，与 trace 关联定位热点。

• USDT
• dynamic uprobe
• overhead

USDT 相对 dynamic uprobe 的 overhead（开销）对比：未启用时，USDT 探针几乎零开销（如 nop 指令，仅编译时保留探针点，运行时无代价）；dynamic uprobe 未启用时也零开销（内核断点机制，未启用无函数调用）。启用时：USDT 通过预埋的 nop/可换指令激活，开销低（一次函数调用级）；uprobe 通过断点（int3）触发，有陷阱处理开销，且每次探测都需内核断点处理。env overhead 指环境/部署开销：USDT 需源码预埋（编译期依赖），uprobe 无需改源码（动态），但 USDT 探针稳定、语义明确。工程上：长期稳定探针用 USDT（低开销、稳定），临时动态探测用 uprobe。

USDT 未启用零开销、启用后低开销且稳定；uprobe 动态灵活但需断点处理。USDT 部署需预埋，uprobe 无需。

• perf record/report
• 硬件计数器 PMC
• 采样模式

perf 的采样模式基于硬件性能计数器（PMC，Performance Monitoring Counter）：perf record 用 PMC 按事件（如 cycles、instructions、cache-misses）以指定频率采样调用栈及计数，perf report 解析采样数据生成报告（按函数/调用栈排序，显示 CPU 占用与热点）。模式：采样（sampling）——按周期/频率采样 PC 与栈，开销低、统计近似；计数（counting）——perf stat 累计事件计数。硬件 PMC 提供精确的 CPU 事件（周期、指令、缓存缺失、分支），采样开销低。perf record -e cycles -g 采样周期事件 + 栈，perf report 展示热点。工程上：用 PMC 采样定位 CPU/缓存/分支热点，低开销持续剖析。

perf record 用 PMC 采样栈与事件，perf report 生成热点报告。采样开销低、统计近似，计数精确。

• USDT 探针
• bpftrace 一行脚本
• 动态追踪

bpftrace 可 attach 到 USDT 探针（usdt:provider:name 语法）或动态 uprobe（uprobe:path:func），用一行脚本定位。示例：usdt:/usr/lib/.../libc.so:malloc { printf("%u\n", pid); } 追踪 malloc 调用；或 uprobe:/path/app:func 追踪任意函数。bpftrace 是 eBPF 前端，一行脚本即可定义探针与动作（打印、计数、直方图），用于快速定位：某函数调用频率、参数、延迟、栈。USDT 探针稳定（源码预埋），动态 uprobe 灵活（任意函数）。工程上：用 bpftrace 一行脚本 attach USDT/uprobe 探针，快速统计函数调用、延迟分布，定位性能或行为问题。

bpftrace 用 usdt:/uprobe: 语法 attach 静态/动态探针，一行脚本计数、测延迟、打印参数，快速定位。