利用perf剖析Linux应用程序

剖析（Profiling）是一种有效的、细粒度的软件性能检查手段，大部分编程语言的生态圈都有各种性能剖析工具。本文的讨论内容与具体编程语言无关，而关注在Linux系统上对应用程序的性能进行剖析。

Linux内核实现了非常有价值的性能分析基础设施（perf infrastructure），可以用于剖析各种CPU或软件事件。这一功能由perf_events接口暴露，并提供 perf这一用户空间工具，通过此工具，你可以发现以下问题的答案：

1. 为什么内核使用太多的CPU，哪些代码使用了这些CPU时间
2. 什么代码导致CPU二级缓存不命中
3. CPU是否因内存IO而卡顿
4. 什么代码在分配内存，分配了多少
5. 什么触发了TCP重传
6. 某个内核函数是否被频繁调用
7. 线程离开CPU的原因 

perf_events是内核2.6+的一部分，用户空间工具perf在包linux-tools-common中，需要安装才能使用。要想从剖析中获得更多内核相关信息，你需要符号（Symbol）和栈追踪，这可能需要安装额外的包，甚至使用特定选项重新编译你的内核。剖析用户空间代码时，也要求目标应用程序的调试信息（符号表）被保留。

perf_events有三种工作模式：

1. counting，在内核上下文对各种指标进行计数
2. sampling，对事件进行采样，并将性能数据存放到内核缓冲，然后异步的写入到perf.data
3. bpf，4.4版本内核引入的新特性，允许在内核中执行一段用户自定义的代码，以执行高效的过滤、汇总

perf_events的采样是基于事件进行的。采样的周期以事件的数量来表示，而非基于时间。当目标事件计数溢出指定的数值，则产生一个采样。

样本中包含的信息取决于用户和工具指定的度量类型，但是最重要的信息是指令指针（instruction pointer），也就是程序被中断时所处的位置。

这种基于中断的采样，在现代处理器上存在刹车效应。也就是说，样本中记录的指针，和程序被中断以处理PMU事件时的指令指针，可能相隔数十个指令。

record子命令默认使用cycle事件，类似于定期采样。

perf_events可以捕获的事件类型包括：

1. 硬件事件，来自CPU自己或CPU的PMU（Performance Monitoring Unit，性能监控单元），包含一系列微架构事件例如时钟周期、L1缓存丢失等。具体支持的事件类型取决于CPU型号
2. 软件事件，基于内核计数器的低级事件，例如CPU迁移、上下文切换、Minor Faults、Major Faults（页面错误）
3. 追踪点事件，由内核中的ftrace实现，包括：
   1. 内核追踪点事件，静态的、内核级的追踪点，硬编码到内核
   2. 用户静态定义追踪（USDT），用户态应用程序硬编码的追踪点
   3. 动态追踪，软件可以被动态instrumented，在任何位置创建事件。对于内核软件，使用kprobes框架，对于用户软件，使用uprobes
   4. 定时追踪，以任意频率抓取快照，主要用于CPU剖析，工作机制是定期引发中断

要启用内核动态追踪，需要使用内核编译参数CONFIG_KPROBES=y、CONFIG_KPROBE_EVENTS=y。要追踪基于帧指针的内核栈，需要内核编译参数CONFIG_FRAME_POINTER=y。

要启用用户动态追踪，需要使用内核编译参数CONFIG_UPROBES=y、CONFIG_UPROBE_EVENTS=y

事件有多种表示方式，最简单的是它的字符串表示。引用事件时，可以指定限定符：

限定符包括：

限定符	说明	示例
u	监控特权级别3, 2, 1 ，也就是用户态	event:u
k	监控特权级别0，也就是内核态	event:k
h	在虚拟化环境下监控Hypervisor事件	event:h
H	在虚拟化环境下监控宿主机事件	event:H
G	在虚拟化环境下监控客户机事件	event:G

perf可以在不同的范围收集性能数据：

1. 单线程（per-thread）：仅仅监控选择的线程。如果线程被调度失去CPU，对它的性能计数暂停，如果线程被调度到其它CPU，计数会存储并恢复，继续在新CPU上进行计数
2. 单进程（ per-process）：进程的所有线程都被监控，计数被汇总
3. 单CPU（ per-cpu）：仅仅监控单颗、或者选定的几颗CPU上的事件
4. 全局（system-wide）：监控所有CPU上的事件

和其它调试工具一样，perf需要符号信息，符号用于将内存地址转换为可读的函数、变量名称。没有符号信息，你会看到0x7ff3c1cddf29这样的HEX代码，无法阅读。

如果需要被剖析的软件通过包管理器安装，你需要找到并安装对应的调试包（可能以-dbgsym为后缀）。如果找不到调试包，可以考虑手工编译。

Java、Node.js等基于虚拟机的语言，在自己的虚拟CPU上执行代码，因而具有自己管理栈和执行函数的方法。

为了通过perf来剖析这类语言的程序，你需要：

1. 对于Java，使用perf-map-agent
2. 对于Node.js，使用命令行选项 --perf_basic_prof

你可能看不到完整的Java栈，这是因为X86上的Hotspot忽略了帧指针（Frame pointer）。在8u60+版本以后，可以使用-XX:+PreserveFramePointer修复这一问题。

为了方便剖析，编译时尽量保留帧指针，编译器的优化行为可能导致难以调试，但是很多情况下优化掉帧指针是默认行为。

缺少帧指针会导致无法看到完整的调用栈，解决此问题的方法有几种：

1. 使用DWARF（ELF文件通常使用的调试信息格式）信息来Unwind栈
2. 使用LBR（Last Branch Record），这是处理器特性，因此可能不可用
3. 保留帧指针

下面是默认情况下编译（-O2，忽略帧指针）得到的OpenSSH的剖析结果：

以 -fno-omit-frame-pointer重新编译后：

可以看到符号都显示出来了，另外add_one_listen_addr的祖先帧也显示出来了。 

你需要使用 CONFIG_FRAME_POINTER=y来编译内核，以保留栈指针信息。

从内核3.9版本开始，缺失栈指针的问题有个变通的解决方案（对于用户空间的栈）——使用libunwind。libunwind基于dwarf，调用perf时传入--call-graph dwarf即可。

在Ubuntu上可以这样安装：

系统可能会提示你安装其它的包，安装即可。

perf支持一系列的子命令：

子命令	说明
annotate	读取perf.data并显示被注解的代码
bench	基准测试的框架
config	在配置文件中读写配置项
diff	读取perf.data并显示剖析差异
evlist	列出perf.data中的事件名称
inject	用于增强事件流的过滤器
kmem	跟踪/度量内核内存属性
kvm	跟踪/度量KVM客户机系统
list	显示符号化的事件列表
lock	分析锁事件
mem	分析内存访问
record	执行剖析
report	显示剖析结果
sched	分析调度器
stat	获取性能计数
top	显示成本最高的操作并动态刷新
trace	类似于strace的工具
probe	定义新的动态追踪点

运行一个命令，并收集性能计数器。

对于任何支持计数的事件，perf都能够在进程执行期间对发生的事件进行计数，计数结果会直接打印在控制台上。

stat子命令可以在线程、进程、CPU、全局级别进行计数。默认情况下进程的所有线程、子进程的计数都被统计在内，可以通过-i选项修改此行为。

参考record子命令。

动态显示执行成本最高的项。

默认情况下以cycles事件采样，样本最高的输出在最顶部。

此命令可以启动一个命令，并对其进行剖析，然后把剖析数据记录到文件（默认perf.data）。按Ctrl - C可以随时结束剖析。

此命令可以在线程、进程、CPU、全局级别进行剖析。

record, report, annotate是一组相关的命名，通常的使用流程是：

1. 在被剖析机器上调用record录制数据
2. 拷贝录制的perf.data，在任意机器上调用report、annotate进行分析

该命令不是记录所有事件，还是进行采样。默认情况下采样基于cycle事件，也就是进行定期采样。

perf_events接口允许通过两种方式描述采样周期：

1. period：事件发生的次数
2. frequency：每秒样本的平均个数

perf默认使用第二种，具体来说对应到-F选项。-F 1000表示1000Hz，也就是每秒平均采样1000个。内核会动态的调整采样周期，以尽量满足需求。

选项	说明
-e	剖析的事件类型，也就是性能监控单元（Performance Monitoring Unit，PMU）类型。可以指定： 事件名称，执行 perf list可以显示支持的事件列表 一组事件，以花括号包围 {event1,event2,...} 其它形式
--filter	事件过滤器，必须和指定了追踪点（tracepoint）事件的-e配合使用
--exclude-perf	不记录perf自己发起的事件
-a	使用Per-CPU模式，如果不指定-C，则相当于全局模式 如果指定-C，则可以选定若干CPU
-p	收集指定进程的事件，逗号分割的PID列表
-t	收集指定线程的事件，逗号分割的线程ID列表
-u	收集指定用户的进程的事件
-r	使用RT SCHED_FIFO优先级收集数据
-c	采样周期
-o	输出文件的名称
-i	不包括子任务的事件，不监控子进程、线程、子进程的线程
-F	以指定的频率剖析
-g	记录调用栈
--call-graph	收集调用栈使用的方法： fp，栈指针 dwarf，DWARF的调用帧信息（CFI） lbr，Hardware Last Branch Record facility 某些系统上，如果应用通过GCC的--fomit-frame-pointer参数构建，fp模式下可能只能看到匿名调用帧，可以用dwarf代替
-s	记录每个线程的事件计数器，配合 perf report -T使用
-d	记录样本地址
-T	记录样本时间戳
-P	记录样本周期
-C	仅仅从指定的CPU上收集样本，示例： -C 0,2-3
-G	仅仅记录指定控制组的事件

此命令用于分析perf record生成的perf.data文件。

选项	说明
-i	指定输入文件
-n	显示每个符号的样本数量
-T	显示每个线程的事件计数器
--pid	仅仅显示指定PID的事件
--tid	仅仅显示指定TID的事件
-s	指定直方图的排序方式，逗号分隔多个排序方式，优先级降序 comm 任务的命令 pid 任务的PID dso 采样时执行的库或者模块的名称 symbol 采样时执行的函数 srcline,srcfile 代码文件和行数，需要DWARF调试信息 overhead  采样的执行成本 overhead_sys 采样在内核态的执行成本 overhead_us 采样在用户态的执行成本 sample 采样数量
-F	指定输出字段，逗号分隔多个字段

默认情况下，样本根据函数（符号）分类，数量最多的样本位于最前面：

各列含义如下：

1. Overhead，在对应函数中采样到的样本计数
2.  Command，样本从什么应用程序中采集到
3. Shared Object，样本来自的ELF镜像。如果：
   1. 应用程序是动态链接的，这里可能显示共享库的名称
   2. 如果样本来自内核空间，则一律显示伪ELF镜像名“kernel.kallsyms”
4. 第4列是特权级别，点号表示用户级别，k、g、u、H分别表示内核级别、客户机内核级别、客户机用户级别、hypervisor
5. 最后一列是符号名称，如果缺乏调试信息，则显示为0x开头的函数内存地址

你可以指定多种分组规则，对样本数进行统计。

下面的例子根据共享对象分组：

下面的例子根据CPU序号分组：

perf不知道如何从压缩内核（vmlinuz）中抽取符号，如果你的内核保留了调试符号，则可以用-k来指出未压缩内核的位置：

如果在record时收集了调用链，则Overhead可以在Children、Self两个列中显示。Children显示子代函数的样本计数、Self显示函数自己的样本计数

此命令用于源码级别的分析。

所有被采样到的函数都会被反汇编，每个指令占据采样的比例会被输出。

如果应用程序以-ggdb编译，annotate还能够生成源码级别信息：

再次强调一下刹车现象，百分比信息可能不准确。

对于压缩内核，你可以指定非压缩版本内核的位置，以解析符号：

显示支持的事件列表。

用于定义新的追踪点，实现动态追踪。

该命令使用额外的信息来增强事件流。

选项	说明
-b	注入build-ids
-v	冗长输出
-i	指定输入文件
-o	指定输出文件
-s	合并sched_stat、sched_switch，以获得任务在何处睡眠、睡眠了多久

进行10秒钟的剖析：

根据应用程序的名称进行分组，整体上根据样本的执行成本进行排序：

可以展开执行成本高的项，追踪到CPU时间都消耗在哪里了：

对于上面这个例子，可以看到，kubelet消耗的资源主要用于Prometheus相关的指标收集，以及grpc的客户端。

perf_events支持使用固定频率来采样指令指针或栈追踪，进而分析CPU使用。采样频率通过-F选项指定。

频率可以选用99，而非100HZ，以避免采样和某些周期性活动的步调完全一致而导致结果失真。如果需要更高分辨率的采样，可以使用997这样的频率，但是注意频率越高剖析本身的成本也越高。

示例：

除了定时触发（固定频率采样），采样也可以由特定的CPU硬件计数器触发。使用这些计数器可以分析缓存丢失、memory stall cycles（由于访问内存而导致的时钟周期浪费，内存访问速度相对CPU时钟周期要慢的多）等更低级别的处理器事件。

可用的事件列表：

如果每当发生这些事件，就记录栈追踪，对系统性能有严重的影响。因此，通常使用-c选项，当计数器增加一定数量后，记录一次栈追踪：

上面这个例子，每当L1缓存丢失10000次，记录一次栈追踪。

下面的命令统计所有调用次数大于0的系统调用的数量：

可以看到，主要的系统调用都是read/write。

使用strace命令可以获得类似的结果，但是strace的成本要高的多。测试结果显示，perf可能让程序变慢2.5倍，而strace则会让程序变慢高达60倍。

追踪点sched:sched_process_exec在某个进程调用exec()产生另外一个进程时生效，这通常是新进程的产生方式。但是这个例子的结果不一定准确，原因是：

1. 进程可能fork()出子进程，追踪点sched:sched_process_fork可以用于这种情况
2. 应用程序可以reexec —— 针对自己再次调用exec() —— 这种用法可以清空地址空间，但是不会产生新进程

某些时候你希望了解服务器发起了哪些网络连接，是哪些进程发起的，为何发起。这些网络连接可能是延迟的根源。

追踪connect系统调用，即可了解出站连接：

可以看到，占比最高的出站连接是由Calico Node容器发起的。

通过剖析套接字缓冲的使用情况，也是定位到什么代码使用了最多的网络I/O的一种方法：

使用perf可以了解应用程序为何休眠、在何处休眠、休眠多久。主要通过收集sched_stat、sched_switch事件实现。

剖析的目标代码如下：

执行下面的命令开始剖析：

合并sched_start、sched_switch事件：

报告：