55、性能分析与事件追踪工具全解析

性能分析与事件追踪工具全解析

在软件开发和系统优化过程中，性能分析和事件追踪是至关重要的环节。通过合适的工具，我们能够深入了解程序的运行情况，找出性能瓶颈，从而进行针对性的优化。本文将介绍几种常用的性能分析和事件追踪工具，包括 perf、Ftrace、LTTng 和 BPF。

1. perf 工具介绍

perf 是一个强大的性能分析工具，它可以帮助我们分析程序的性能瓶颈。然而，使用 perf 时，列表顶部的函数大多是底层内存操作，这些操作通常已经经过了优化。不过，perf record 提供了一个有用的功能，即可以沿着调用栈向上追溯，查看这些函数是在何处被调用的。

1.1 调用图（Call graphs）

为了更全面地了解高成本函数的上下文，我们可以在 perf record 中使用 -g 选项来捕获每个样本的回溯信息。这样，perf report 会在函数属于调用链的位置显示一个加号（+），我们可以展开跟踪信息，查看调用链中更底层的函数。

需要注意的是，生成调用图依赖于从栈中提取调用帧的能力，这与 GDB 中的回溯功能类似。展开栈所需的信息编码在可执行文件的调试信息中，但并非所有架构和工具链的组合都能实现这一点。

1.2 perf annotate

当我们知道要查看哪些函数后，就可以使用 perf annotate 深入查看这些函数的代码，并获取每条指令的命中计数。perf annotate 通过调用目标设备上安装的 objdump 来实现这一功能，我们只需用 perf annotate 替代 perf report 即可。

perf annotate 需要可执行文件和 vmlinux 的符号表。如果我们想查看汇编代码与源代码交织的情况，可以将相关的源文件复制到目标设备上。如果使用 Yocto Project 并启用了 dbg - pkgs 额外镜像功能，或者安装了单独的 -dbg 包，那么源文件会被安装在 /usr/src/debug 目录下。否则，我们可以通过检查调试信息来查看源代码的位置，例如：

$ arm - buildroot - linux - gnueabi - objdump --dwarf lib/libc - 2.19.so | grep DW_AT_comp_dir
<3f> DW_AT_comp_dir : /home/chris/buildroot/output/build/hostgcc - initial - 4.8.3/build/arm - buildroot - linux - gnueabi/libgcc

目标设备上的路径应与 DW_AT_comp_dir 中显示的路径完全相同。

2. 事件追踪工具概述

前面介绍的工具主要使用统计采样方法。但在很多情况下，我们更想了解事件的顺序，以便将它们关联起来。函数追踪通过在代码中插入跟踪点来捕获事件信息，这些信息可能包括时间戳、上下文（如当前 PID）、函数参数和返回值以及调用栈等。与统计采样相比，函数追踪更具侵入性，并且会生成大量数据。不过，我们可以在捕获样本和查看跟踪信息时应用过滤器来缓解这个问题。

接下来将介绍三种追踪工具：内核函数追踪器 Ftrace、LTTng 和 BPF。

3. Ftrace 工具介绍

Ftrace 是一个内核函数追踪器，它源于 Steven Rostedt 等人在追踪实时应用中高调度延迟原因的工作。Ftrace 于 Linux 2.6.27 版本中首次出现，并自那时起得到了积极的开发。内核源代码的 Documentation/trace 目录中有许多关于内核追踪的文档。

3.1 Ftrace 组成

Ftrace 由多个追踪器组成，可以记录内核中各种类型的活动。这里主要介绍函数追踪器（function tracer）、函数图追踪器（function_graph tracer）和事件跟踪点（trace events）。

• 函数追踪器 ：对每个内核函数进行插桩，记录函数调用并添加时间戳。实际上，它通过在编译内核时使用 -pg 开关来注入插桩代码。
• 函数图追踪器 ：不仅记录函数的进入，还记录函数的退出，从而可以创建调用图。
• 事件跟踪点 ：除了记录函数执行时间外，还记录与调用相关的参数，使跟踪信息更加可读和有信息量。

3.2 准备使用 Ftrace

要使用 Ftrace，需要在核配置菜单中进行一些配置。至少需要启用以下选项：
- CONFIG_FUNCTION_TRACER ：位于 Kernel hacking | Tracers | Kernel Function Tracer 菜单中。
为了获得更好的使用体验，建议同时启用以下选项：
- CONFIG_FUNCTION_GRAPH_TRACER ：位于 Kernel hacking | Tracers | Kernel Function Graph Tracer 菜单中。
- CONFIG_DYNAMIC_FTRACE ：位于 Kernel hacking | Tracers | enable/disable function tracing dynamically 菜单中。

由于整个系统都在核中运行，因此无需进行用户空间配置。

3.3 使用 Ftrace

在使用 Ftrace 之前，需要挂载 debugfs 文件系统，通常挂载到 /sys/kernel/debug 目录：

# mount -t debugfs none /sys/kernel/debug

Ftrace 的所有控制文件都位于 /sys/kernel/debug/tracing 目录下，该目录下的 README 文件中甚至还有一个简单的使用指南。

我们可以通过以下命令查看内核中可用的追踪器列表：

# cat /sys/kernel/debug/tracing/available_tracers
blk function_graph function nop

当前活动的追踪器由 current_tracer 文件显示，初始时为 null 追踪器 nop。

要捕获跟踪信息，我们可以选择一个可用的追踪器，并启用追踪一段时间，示例如下：

# echo function > /sys/kernel/debug/tracing/current_tracer
# echo 1 > /sys/kernel/debug/tracing/tracing_on
# sleep 1
# echo 0 > /sys/kernel/debug/tracing/tracing_on

在这一秒内，跟踪缓冲区将被内核调用的每个函数的详细信息填满。我们可以从 trace 文件中读取跟踪缓冲区的内容：

# cat /sys/kernel/debug/tracing/trace

如果选择 function_graph 追踪器，Ftrace 会捕获调用图，我们可以看到函数调用的嵌套关系，并用花括号 { 和 } 分隔。在结束的花括号处，会显示函数执行所花费的时间，如果时间超过 10 µs 会用加号（+）标注，如果超过 100 µs 会用感叹号（!）标注。

如果我们只对单个进程或线程引起的内核活动感兴趣，可以通过将线程 ID 写入 set_ftrace_pid 来限制跟踪范围。

3.4 动态 Ftrace 和跟踪过滤器

启用 CONFIG_DYNAMIC_FTRACE 允许 Ftrace 在运行时修改函数跟踪点，这带来了两个好处。首先，它会触发对跟踪函数探针的额外构建时处理，使 Ftrace 子系统在启动时能够定位这些探针，并用 NOP 指令覆盖它们，从而将函数跟踪代码的开销几乎降为零。这样，我们可以在生产环境或接近生产环境的内核中启用 Ftrace，而不会对性能产生影响。

其次，我们可以选择性地启用函数跟踪点，而不是跟踪所有内容。可用的函数列表存储在 available_filter_functions 文件中，有几万个函数。我们可以根据需要从 available_filter_functions 中复制函数名到 set_ftrace_filter 来选择性地启用函数跟踪，通过将函数名写入 set_ftrace_notrace 来停止跟踪该函数。我们还可以使用通配符并追加函数名到列表中，例如：

# cd /sys/kernel/debug/tracing
# echo "tcp*" > set_ftrace_filter
# echo function > current_tracer
# echo 1 > tracing_on

运行一些测试后，查看跟踪信息：

# cat trace

set_ftrace_filter 函数还可以包含一些命令，例如在某些函数执行时开始和停止跟踪。如果想了解更多细节，可以阅读 Documentation/trace/ftrace.txt 中的 Filter commands 部分。

3.5 跟踪事件（Trace events）

前面介绍的函数和函数图追踪器只记录函数执行的时间，而跟踪事件功能还会记录与调用相关的参数，使跟踪信息更加可读和有信息量。例如，跟踪事件不仅会记录 kmalloc 函数被调用，还会记录请求的字节数和返回的指针。

跟踪事件在 perf、LTTng 和 Ftrace 中都有应用，其开发最初是由 LTTng 项目推动的。内核开发者需要付出一定的努力来创建跟踪事件，每个事件都使用 TRACE_EVENT 宏在源代码中定义，目前已经有一千多个这样的事件。我们可以在 /sys/kernel/debug/tracing/available_events 中查看运行时可用的事件列表，这些事件的命名格式为 subsystem:function，例如 kmem:kmalloc。

每个事件在 tracing/events/[subsystem]/[function] 目录下都有一个对应的子目录，包含以下文件：
- enable ：写入 1 以启用该事件。
- filter ：一个表达式，该表达式必须计算为 true 才能跟踪该事件。
- format ：事件和参数的格式。
- id ：一个数字标识符。
- trigger ：当事件发生时执行的命令，其语法在 Documentation/trace/ftrace.txt 的 Filter commands 部分定义。

下面是一个简单的示例，涉及 kmalloc 和 kfree 事件：

# echo nop > current_tracer
# echo 1 > events/kmem/kmalloc/enable
# echo 1 > events/kmem/kfree/enable
# echo "kmem:kmalloc kmem:kfree" > set_event

现在，当我们读取跟踪信息时，就可以看到函数及其参数：

# cat /sys/kernel/debug/tracing/trace

4. LTTng 工具介绍

LTTng 是 Linux 内核中常用的事件追踪工具，它的前身是 Linux Trace Toolkit（LTT）项目。后来，Mathieu Desnoyers 将其重新实现为下一代跟踪工具 LTTng，并扩展到涵盖用户空间跟踪以及内核跟踪。

4.1 LTTng 组成

LTTng 由三个组件组成：
- 核心会话管理器 ：负责管理跟踪会话。
- 内核追踪器 ：以一组内核模块的形式实现。
- 用户空间追踪器 ：以库的形式实现。

此外，我们还需要一个跟踪查看器，如 Babeltrace 或 Eclipse Trace Compass 插件，来显示和过滤主机或目标设备上的原始跟踪数据。

4.2 LTTng 配置

LTTng 需要一个配置了 CONFIG_TRACEPOINTS 的内核，当选择 Kernel hacking | Tracers | Kernel Function Tracer 时该选项会被启用。

如果使用 Yocto Project，需要在 conf/local.conf 中添加以下包到目标依赖项中：

IMAGE_INSTALL_append = " lttng - tools lttng - modules lttng - ust"

如果想在目标设备上运行 Babeltrace，还需要追加 babeltrace 包。

如果使用 Buildroot，需要启用以下选项：
- BR2_PACKAGE_LTTNG_MODULES ：在 Target packages | Debugging, profiling and benchmark | lttng - modules 菜单中。
- BR2_PACKAGE_LTTNG_TOOLS ：在 Target packages | Debugging, profiling and benchmark | lttng - tools 菜单中。
对于用户空间跟踪，还需要启用：
- BR2_PACKAGE_LTTNG_LIBUST ：在 Target packages | Libraries | Other, enable lttng - libust 菜单中。

4.3 使用 LTTng 进行内核跟踪

LTTng 可以使用前面介绍的 Ftrace 事件作为潜在的跟踪点，初始时这些事件是禁用的。

LTTng 的控制接口是 lttng 命令，我们可以使用以下命令列出内核探针：

# lttng list --kernel

要捕获跟踪信息，我们需要创建一个会话，例如：

# lttng create test

然后在当前会话中启用一些事件，这里我们启用了几个与调度器相关的跟踪事件：

# lttng enable - event --kernel sched_switch,sched_process_fork

可以使用以下命令检查配置是否正确：

# lttng list test

开始跟踪：

# lttng start

运行测试负载，然后停止跟踪：

# lttng stop

会话的跟踪信息会写入会话目录 lttng - traces/ /kernel 中。

我们可以使用 Babeltrace 查看器以文本格式转储原始跟踪数据，例如在主机上运行：

$ babeltrace lttng - traces/test - 20150824 - 140942/kernel

如果想使用图形化的跟踪查看器，可以选择 Eclipse 的 Trace Compass 插件。导入跟踪数据到 Eclipse 的步骤如下：
1. 打开 Tracing 透视图。
2. 选择 File | New | Tracing project 创建一个新项目。
3. 输入项目名称并点击 Finish。
4. 在 Project Explorer 菜单中右键单击新项目选项，选择 Import。
5. 展开 Tracing，然后选择 Trace Import。
6. 浏览到包含跟踪信息的目录（例如 test - 20150824 - 140942），勾选要导入的子目录（可能是 kernel），然后点击 Finish。
7. 展开项目，再展开 Traces[1]，然后双击 kernel。

5. BPF 工具介绍

BPF（Berkeley Packet Filter）最初于 1992 年被引入，用于捕获、过滤和分析网络流量。2013 年，Alexi Starovoitov 在 Daniel Borkmann 的帮助下对 BPF 进行了重写，当时称为 eBPF（extended BPF），并于 2014 年合并到内核中，从 Linux 3.15 版本开始可用。

BPF 为在 Linux 内核中运行程序提供了一个沙箱执行环境。BPF 程序用 C 语言编写，并通过即时编译（JIT）转换为本地代码。在此之前，中间的 BPF 字节码必须通过一系列安全检查，以确保程序不会导致内核崩溃。

综上所述，perf、Ftrace、LTTng 和 BPF 这些工具各有特点和适用场景。在实际应用中，我们可以根据具体需求选择合适的工具，以深入了解程序的运行情况，优化系统性能。

性能分析与事件追踪工具全解析

6. 工具对比与选择

为了更清晰地了解各个工具的特点和适用场景，我们可以通过以下表格进行对比：
| 工具名称 | 主要功能 | 适用场景 | 优点 | 缺点 |
| — | — | — | — | — |
| perf | 性能分析，可生成调用图、查看汇编和源代码 | 分析程序性能瓶颈，定位高成本函数 | 功能强大，能深入分析函数调用和代码执行情况 | 输出结果可能较复杂，对于底层内存操作分析价值有限 |
| Ftrace | 内核函数追踪，记录函数调用、时间戳和参数 | 追踪内核活动，分析实时应用调度延迟 | 嵌入式友好，无需安装额外工具，可动态配置 | 可能产生大量数据，需要合理使用过滤器 |
| LTTng | 内核和用户空间追踪，可使用 Ftrace 事件 | 全面追踪系统活动，关联内核和用户空间事件 | 功能全面，支持多种查看器 | 配置相对复杂，需要特定内核选项 |
| BPF | 提供内核沙箱执行环境，用于网络流量分析等 | 网络流量捕获、过滤和分析，内核程序执行 | 安全性高，可在不影响内核稳定性的前提下运行程序 | 对开发者要求较高，需要掌握 C 语言和 BPF 相关知识 |

在选择工具时，我们可以参考以下流程图：

graph TD;
    A[确定分析目标] --> B{是否关注内核活动};
    B -- 是 --> C{是否需要用户空间追踪};
    C -- 是 --> D[选择 LTTng];
    C -- 否 --> E{是否需要详细的函数调用信息};
    E -- 是 --> F[选择 Ftrace];
    E -- 否 --> G{是否主要进行性能分析};
    G -- 是 --> H[选择 perf];
    G -- 否 --> I[根据具体需求选择其他工具];
    B -- 否 --> J{是否进行网络流量分析};
    J -- 是 --> K[选择 BPF];
    J -- 否 --> I;

7. 实际应用案例

下面通过一个实际应用案例来展示如何使用这些工具进行系统性能优化。

假设我们有一个嵌入式系统，在运行过程中出现了性能瓶颈，我们怀疑是内核函数调用或用户空间程序执行效率问题。

7.1 使用 perf 进行初步性能分析

首先，我们使用 perf 来找出可能的性能瓶颈函数。

# 记录性能数据
perf record -g -a sleep 10
# 查看性能报告
perf report

通过 perf report 的输出，我们可以看到哪些函数占用了较多的 CPU 时间，从而确定需要进一步分析的函数。

7.2 使用 Ftrace 深入分析内核函数

如果发现性能瓶颈与内核函数有关，我们可以使用 Ftrace 来深入分析这些函数的调用情况。

# 挂载 debugfs 文件系统
mount -t debugfs none /sys/kernel/debug
# 选择 function_graph 追踪器
echo function_graph > /sys/kernel/debug/tracing/current_tracer
# 启用追踪
echo 1 > /sys/kernel/debug/tracing/tracing_on
# 运行一段时间
sleep 5
# 停止追踪
echo 0 > /sys/kernel/debug/tracing/tracing_on
# 查看跟踪信息
cat /sys/kernel/debug/tracing/trace

通过查看跟踪信息，我们可以了解函数调用的嵌套关系和执行时间，找出可能存在性能问题的函数调用路径。

7.3 使用 LTTng 关联内核和用户空间事件

如果性能问题涉及到内核和用户空间的交互，我们可以使用 LTTng 来全面追踪系统活动。

# 创建会话
lttng create test
# 启用内核和用户空间事件
lttng enable-event --kernel sched_switch,sched_process_fork
lttng enable-event --userspace myapp:*
# 开始跟踪
lttng start
# 运行测试负载
./myapp
# 停止跟踪
lttng stop
# 使用 Babeltrace 查看跟踪信息
babeltrace lttng-traces/test-<timestamp>/kernel lttng-traces/test-<timestamp>/userspace

通过 LTTng 的跟踪信息，我们可以关联内核和用户空间的事件，找出可能存在的性能瓶颈点。

7.4 使用 BPF 进行网络流量分析

如果性能问题与网络流量有关，我们可以使用 BPF 来捕获、过滤和分析网络流量。

// 示例 BPF 程序
#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>

SEC("prog")
int my_bpf_prog(struct __sk_buff *skb) {
    // 过滤特定 IP 地址的数据包
    if (skb->protocol == htons(ETH_P_IP)) {
        struct iphdr *iph = (struct iphdr *)(skb->data + skb->mac_header);
        if (iph->daddr == htonl(0x01020304)) {
            // 处理数据包
            bpf_printk("Received packet from IP: %x\n", iph->saddr);
        }
    }
    return 0;
}

char _license[] SEC("license") = "GPL";

将上述代码保存为一个 .c 文件，然后使用 BPF 工具链进行编译和加载。

# 编译 BPF 程序
clang -g -O2 -target bpf -D__TARGET_ARCH_x86 -I/usr/include/x86_64-linux-gnu -c my_bpf_prog.c -o my_bpf_prog.o
# 加载 BPF 程序
ip link set dev eth0 xdp obj my_bpf_prog.o sec prog

通过 BPF 程序，我们可以实时捕获和分析网络流量，找出可能存在的网络性能问题。

8. 总结与展望

通过本文的介绍，我们了解了 perf、Ftrace、LTTng 和 BPF 这几种常用的性能分析和事件追踪工具的特点、使用方法和适用场景。在实际应用中，我们可以根据具体需求选择合适的工具，结合使用这些工具可以更全面地了解系统的运行情况，找出性能瓶颈并进行优化。

随着计算机技术的不断发展，这些工具也在不断更新和完善。未来，我们可以期待这些工具在功能上更加强大，使用更加便捷，为系统性能优化提供更好的支持。同时，新的性能分析和事件追踪技术也可能会不断涌现，我们需要持续关注和学习，以适应不断变化的技术环境。