差生文具多之(二): perf

栈回溯和符号解析是使用 perf 的两大阻力，本文以应用程序 fio 的观测为例子，提供一些处理它们的经验法则，希望帮助大家无痛使用 perf。

前言

系统级性能优化通常包括两个阶段：性能剖析和代码优化：

  1. 性能剖析的目标是寻找性能瓶颈，查找引发性能问题的原因及热点代码;

  2. 代码优化的目标是针对具体性能问题而优化代码或调整编译选项，以改善软件性能。

在步骤一性能剖析阶段，最常用的工具就是 perf。perf 是 linux 官方提供的性能分析工具，被包含在 Linux 内核源码树中。它是一个庞大的工具集合，功能相当繁杂。但在工作中，通常我们只会使用到 perf 其中相当小的一个子集，主要包含以下四个步骤:

  1. perf record: 采集数据，采的时间越长越心安;

  2. perf report: 查看采集数据，因为采集太长时间，解析数据会卡很久，我们试图理解数据，通常无法理解;

  3. perf script: 尝试查看原始采样点，通常无法理解；

  4. 生成火焰图: 色彩丰富，通常发给领导理解。

综上，后三个步骤是我们无法控制的，本文主要聊聊如何在步骤一尽量生成可信的采样数据。

workflow of perf

虽然听起来调侃，但上述步骤确实是标准的分析流程，毕竟有火焰图发明人 Brandon 的背书:

@Brandon

可以看到，它们被包含在 perf 工作流第三列的 capture stacks 中，简单回顾一下这四个步骤:

  1. perf record: 通过指定 -g 选项可以收集系统整体的函数调用栈(包含用户态和内核态)，默认以 4000HZ 的频率收集，大约每秒生成 4000 个采样点，被保存在 perf.data 文件中;

$ perf record -g -C 0 -- sleep 1
[ perf record: Captured and wrote 0.906 MB perf.data (4001 samples) ]

  1. perf report: 通过解析 perf.data，生成热点函数占用 CPU 的比例。例如以下输出中，CPU0 大部分时间(99.73%)停留在内核代码的 idle 函数中，即 CPU0 大部分时间处于空闲状态:

$ perf report --no-child --stdio
99.73%  swapper          [kernel.kallsyms]  [k] native_safe_halt|---native_safe_haltacpi_idle_do_entryacpi_idle_entercpuidle_enter_statecpuidle_enterdo_idlecpu_startup_entrystart_kernelsecondary_startup_64_no_verify

  1. perf script: 查看每个采样样本(栈)，例如以下栈样本表明: cpu-clock:pppH: 事件于时间 45399.463561 发生，在 CPU0 触发了中断，中断打断的任务是进程号为 0 的内核线程 swapper，栈从下往上看，被打断时 CPU 正在执行 native_safe_halt 偏移 0xe 处的指令:

$ perf script
swapper     0 [000] 45399。463561:     250000 cpu-clock:pppH: ffffffffa234c45e native_safe_halt+0xe ([kernel.kallsyms])ffffffffa234c806 acpi_idle_do_entry+0x46 ([kernel.kallsyms])ffffffffa1f4bafb acpi_idle_enter+0x9b ([kernel.kallsyms])ffffffffa211efb7 cpuidle_enter_state+0x87 ([kernel.kallsyms])ffffffffa211f33c cpuidle_enter+0x2c ([kernel.kallsyms])ffffffffa1b16ff4 do_idle+0x234 ([kernel.kallsyms])ffffffffa1b171ef cpu_startup_entry+0x6f ([kernel.kallsyms])ffffffffa3601262 start_kernel+0x518 ([kernel.kallsyms])ffffffffa1a00107 secondary_startup_64_no_verify+0xc2 ([kernel.kallsyms])

  1. 使用脚本生成火焰图，以下是官网例图:

可以发现，后续的分析步骤都基于步骤一采集得到的 perf.data。显然，只有获取到足够精准的调用栈信息，后续才能准确定位到性能瓶颈。可惜的是，获取函数调用栈并没有一个通用解，导致我们需要额外了解一些小知识。

choose your unwinder

获取函数调用栈过程又称栈回溯（unwind），栈回溯的方法被称为 unwinder，常见的 unwinder 有：

  1. fp：perf 默认选项，ARM 和 X86 都支持，消耗低；

  2. dwarf：通过 --call-graph=dwarf 指定，ARM 和 X86 都支持，对CPU和磁盘消耗高；

  3. lbr：通过 --call-graph=lbr 指定，仅 Intel 新型号支持，消耗低，但可回溯的栈深度有限；

  4. orc：内核 unwinder，无需指定。 在 perf record 中，若不通过 --call-graph 指定 unwinder，默认使用 fp 作为用户态栈的 unwinder；至于内核态的 unwinder，不由 perf 参数指定，由内核编译选项控制，低版本内核使用 fp，高版本内核使用 orc。

因此问题转化为：用户态使用哪个 unwinder 是更合适的？结论先行，以下是可供参考的方案：

  1. Intel CPU：优先使用 lbr，lbr 的好处是硬件实现，精准可靠，大部分情况下深度够用；

  2. ARM 架构：优先使用 fp，因为 ARM 架构寄存器比较多，保留了寄存器记录栈基址；

  3. X86 上没有 lbr 时：优先使用 dwarf，虽然 X86 架构也把栈基址保存在 %rbp，但只要编译优化大于等于 -O1 ，%rbp 寄存器基本作为通用寄存器使用，使得在 X86 上用 fp 获取用户态栈大部分时候不可靠。有以下注意点：

    1. 在 linux 5.19 版本以下，dwarf 可能采样不到动态链接库的栈（参考提交 perf unwind: Fix egbase for ld.lld linked objects）；

    2. dwarf 需要复制保存每一个采样点的用户栈，因此采样期间 CPU 消耗较高，生成的采样数据也远大于其它 unwinder；

    3. 如果 dwarf 无法满足需求，可以 gcc 编译时添加选项 -fno-omit-frame-pointer 放弃复用 %rbp 寄存器的编译优化，重新编译应用后使用 fp。虽然该选项无法百分百保证 %rbp 一定可靠，但总体可信。

让我们通过在 X86 架构上观测应用程序 fio，对这些 unwinder 有个初步的了解：

$ perf record -a --user-callchains --call-graph=dwarf -p `pidof fio` -o perf.data.dwarf -- sleep 2
$ perf report --no-ch --stdio -i perf.data.dwarf10.69%  fio      [kernel.kallsyms]  [k] iowrite16|---syscallio_submit0x55a0a986682e # <- 我们会在下下节解决符号问题td_io_committd_io_queue0x55a0a985945a <-0x55a0a985b7d0 <- start_thread__GI___clone (inlined)
$ perf record -a --user-callchains --call-graph=fp -p `pidof fio` -o perf.data.fp -- sleep 2
$ perf report --no-ch --stdio -i perf.data.fp8.27%  fio      [kernel.kallsyms]  [k] iowrite16|---syscall|--0.75%--0x70700000707|--0.75%--0x62d0000062d|--0.75%--0x5e1000005e1|--0.75%--0x55b0000055a|--0.75%--0x54800000548|--0.75%--0x52f0000052f|--0.75%--0x51000000510|--0.75%--0x44f0000044f|--0.75%--0x3cb000003cb|--0.75%--0x39800000398--0.75%--0x37c0000037b

以上采集数据的命令中使用 --user-callchains 选项指定了 perf 采样时只采集用户栈，排除掉我们暂时不关心的内核栈。输出中可以看到虽然 dwarf 采集得到的栈没有被完全翻译，但正确地回溯到了进程刚诞生的函数 __GI___clone，这表明 dwarf 采样得到了完整的栈；反观 fp，只得到了些奇怪的地址。我们的方案三是有效的！

what do dwarf do

为叙述完整，该节补充一点 dwarf 栈回溯原理，不影响 perf 使用，不涉及的朋友可以跳转下一节解决符号问题。

在编译过程中 gcc 无论是否指定 -g 选项, 默认都会生成 .eh_frame 和 .eh_frame_hdr 段. gcc 在翻译代码为汇编代码时, 会帮忙插上一些 CFI 伪指令, 如

$ gcc -S test.c           # c语言生成汇编代码
$ vim test.s              # 查看汇编代码
$ cat test.s.cfi_startproc # 刚进函数, 当前我们处于 callee 栈帧的起始处, 更新 CFA = rsp + 8pushq %rbp# 每次 push 寄存器到栈上, 需要将 CFA += 8, 因为相比上一状态需要多往前走一个单位才是 caller 的栈帧.cfi_def_cfa_offset 16.cfi_offset 6, -16 # 并且更新该寄存器关于 CFA 的偏移, 使回溯过程可以恢复该寄存器的值# ...movq %rsp %rbp # 将 rsp 寄存器赋值给 rbp.cfi_def_cfa_register 6 # 将寄存器 6 (rbp) 定义为 CFA 寄存器, 之后 CFA 的计算都基于 rbp# ...leave.cfi_def_cfa 7, 8 # leave 中将 rbp 寄存器的值赋值给 rsp, 即 rsp 此时指向 callee 栈帧开始处, 此时 CFA = rsp + 8.cfi_endproc
$ readelf -wF test.o # 查看对应的 .eh_frame 印证
0000000000000661 rsp+8    u     c-8   
0000000000000662 rsp+16   c-16  c-8   
0000000000000665 rbp+16   c-16  c-8   
00000000000006a6 rsp+8    c-16  c-8 

其中 CFA (Canonical Frame Address, which is the address of %rsp in the caller frame) 指上一级调用者的堆栈指针.

如上所示, 汇编器会将这些 CFI 伪指令收集到可执行文件中的 .eh_frame 段. 典型形式如下:

$ readelf -wF a.out 
Contents of the .eh_frame section:00000000 0000000000000014 00000000 CIE "zR" cf=1 df=-8 ra=16LOC           CFA      ra    
0000000000000000 rsp+8    u     ...000000c8 0000000000000044 0000009c FDE cie=00000030 pc=00000000000006b0..0000000000000715LOC           CFA      rbx   rbp   r12   r13   r14   r15   ra    
00000000000006b0 rsp+8    u     u     u     u     u     u     c-8   
00000000000006b2 rsp+16   u     u     u     u     u     c-16  c-8   
00000000000006b4 rsp+24   u     u     u     u     c-24  c-16  c-8   
00000000000006b9 rsp+32   u     u     u     c-32  c-24  c-16  c-8   
00000000000006bb rsp+40   u     u     c-40  c-32  c-24  c-16  c-8   
00000000000006c3 rsp+48   u     c-48  c-40  c-32  c-24  c-16  c-8   
00000000000006cb rsp+56   c-56  c-48  c-40  c-32  c-24  c-16  c-8   
00000000000006d8 rsp+64   c-56  c-48  c-40  c-32  c-24  c-16  c-8   
000000000000070a rsp+56   c-56  c-48  c-40  c-32  c-24  c-16  c-8   
000000000000070b rsp+48   c-56  c-48  c-40  c-32  c-24  c-16  c-8   
000000000000070c rsp+40   c-56  c-48  c-40  c-32  c-24  c-16  c-8   
000000000000070e rsp+32   c-56  c-48  c-40  c-32  c-24  c-16  c-8   
0000000000000710 rsp+24   c-56  c-48  c-40  c-32  c-24  c-16  c-8   
0000000000000712 rsp+16   c-56  c-48  c-40  c-32  c-24  c-16  c-8   
0000000000000714 rsp+8    c-56  c-48  c-40  c-32  c-24  c-16  c-8  

可以看到 .eh_frame 总体架构由 CIE 和 FDE 组成。通常一个 CIE 代表一个文件, 一个 FDE 代表一个函数. 其中核心的是 FDE 的组织:

利用 .eh_frame 进行栈 unwind 时候, 遵循以下步骤:

  1. 根据当前的PC在.eh_frame中找到对应的条目，根据条目提供的各种偏移计算其他信息。

  2. 首先根据CFA = rsp+4，把当前rsp+4得到CFA的值。再根据CFA的值计算出通用寄存器和返回地址在堆栈中的位置。

  3. 通用寄存器栈位置计算。例如：rbx = CFA-56。

  4. 返回地址ra的栈位置计算。ra = CFA-8。

  5. 根据ra的值，重复步骤1到4，就形成了完整的栈回溯。

handle missing symbols

函数调用栈本质是一串地址，perf 会尽量将地址翻译人类可读的符号。在以下样本点中，可以看到 IP 寄存器保存的地址属于 libc 库，它被正确翻译为 syscall+0x1d，但再往下回溯，我们只知道 syscall 函数是由 libaio 库某不知名函数调用的。这里出现 [unknown] 通常由于可执行程序的符号被裁剪所致，裁剪符号是有效减小可执行程序体积的做法。

$ perf script -D -i perf.data.dwarf
259594741631398 0x2d840 [0x20f8]: PERF_RECORD_SAMPLE(IP, 0x1): 273245/273258: 0xffffffff89d1869d period: 250000 addr: 0
... FP chain: nr:0
[...]
.... IP    0x00007f3afb87f52d
... ustack: size 8192, offset 0xe0
[...]
fio 273258 259594.741631:     250000 cpu-clock:pppH: 7f3afb87f52d syscall+0x1d (/usr/lib64/libc-2.28.so)7f3afc50ab7d [unknown] (/usr/lib64/libaio.so.1.0.1)55a0a9866a95 [unknown] (/usr/bin/fio)55a0a98197a5 td_io_getevents+0x75 (/usr/bin/fio)55a0a983b216 io_u_queued_complete+0x66 (/usr/bin/fio)55a0a98577d4 [unknown] (/usr/bin/fio)55a0a98591fa [unknown] (/usr/bin/fio)55a0a985b7d0 [unknown] (/usr/bin/fio)7f3afc0db179 start_thread+0xe9 (/usr/lib64/libpthread-2.28.so)7f3afb884dc2 __GI___clone+0x42 

那怎么将符号补全呢？我们可以通过安装 -debuginfo 或 -dbgsym 包解决，例如对于 fio：

# centos 上，先使能 yum 的 debuginfo 源，再安装对应应用的 -debuginfo 包即可
$ cat /etc/yum.repos.d/CentOS-Linux-Debuginfo.repo 
[debuginfo]
name=CentOS Linux $releasever - Debuginfo
baseurl=http://debuginfo.centos.org/$releasever/$basearch/
gpgcheck=0
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial
$ yum clean all && yum makecache
$ yum -y install fio-debuginfo.x86_64# ubuntu 上，先导入调试符号签名密钥，再安装对应应用的 -dbgsym 包即可
$ apt install ubuntu-dbgsym-keyring
$ apt install fio-dbgsym

补全后的栈如下所示：

$ perf script -i perf.data.dwarf
fio  2469  2823.211391:     250000 cpu-clock:pppH: 7f03631a89bd syscall+0x1d (/usr/lib64/libc-2.28.so)7f0363ef1c14 io_submit+0x34 (/usr/lib64/libaio.so.1.0.1)555976f418ce fio_libaio_commit+0xde (/usr/bin/fio)555976ef4a98 td_io_commit+0x58 (/usr/bin/fio)555976ef4fb5 td_io_queue+0x3f5 (/usr/bin/fio)555976f344ea do_io+0x71a (/usr/bin/fio)555976f36880 thread_main+0x18b0 (/usr/bin/fio)555976f38561 run_threads+0xcb1 (/usr/bin/fio)

后记

当你面对一个性能问题，如果选择使用 perf 观测，那么问题就变成了三个，另外两个是在解决性能问题前，必须先解决栈回溯和符号解析，前者影响观测准确性，后者影响观测可读性。perf 大部分时候都帮忙做好了，但如果遇到了些小困难，希望本文能有幸帮上一点忙。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mzph.cn/news/384944.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

Linux下的I/O复用与epoll详解(ET与LT)

Linux下的I/O复用与epoll详解(ET与LT)

前言 I/O多路复用有很多种实现。在linux上&#xff0c;2.4内核前主要是select和poll&#xff0c;自Linux 2.6内核正式引入epoll以来&#xff0c;epoll已经成为了目前实现高性能网络服务器的必备技术。尽管他们的使用方法不尽相同&#xff0c;但是本质上却没有什么区别。本文将重…
阅读更多...
彻底学会使用epoll(一)——ET模式实现分析

彻底学会使用epoll(一)——ET模式实现分析

注&#xff1a;之前写过两篇关于epoll实现的文章&#xff0c;但是感觉懂得了实现原理并不一定会使用&#xff0c;所以又决定写这一系列文章&#xff0c;希望能够对epoll有比较清楚的认识。是请大家转载务必注明出处&#xff0c;算是对我劳动成果的一点点尊重吧。另外&#xff0…
阅读更多...
sys/queue.h分析(图片复制不过来，查看原文)

sys/queue.h分析(图片复制不过来，查看原文)

这两天有兴趣学习使用了下系统头文件sys/queue.h中的链表/队列的实现&#xff0c;感觉实现的很是优美&#xff0c;关键是以后再也不需要自己实现这些基本的数据结构了&#xff0c;哈哈&#xff01; 我的系统环境是 正好需要使用队列&#xff0c;那么本篇就以其中的尾队列&…
阅读更多...
线程池原理及C语言实现线程池

线程池原理及C语言实现线程池

备注&#xff1a;该线程池源码参考自传直播客培训视频配套资料&#xff1b; 源码&#xff1a;https://pan.baidu.com/s/1zWuoE3q0KT5TUjmPKTb1lw 密码&#xff1a;pp42 引言&#xff1a;线程池是一种多线程处理形式&#xff0c;大多用于高并发服务器上&#xff0c;它能合理有效…
阅读更多...
iptables 的mangle表

iptables 的mangle表

mangle表的主要功能是根据规则修改数据包的一些标志位&#xff0c;以便其他规则或程序可以利用这种标志对数据包进行过滤或策略路由。 内网的客户机通过Linux主机连入Internet&#xff0c;而Linux主机与Internet连接时有两条线路&#xff0c;它们的网关如图所示。现要求对内网进…
阅读更多...
Linux之静态库

Linux之静态库

命名规则&#xff1a; lib 库的名字 .a 制作步骤 生成对应.o文件 .c .o 将生成的.o文件打包 ar rcs 静态库的名字&#xff08;libMytest.a&#xff09; 生成的所有的.o 发布和使用静态库&#xff1a; 1&#xff09; 发布静态 2&#xff09; 头文件 文件如下图所示&…
阅读更多...
Linux之动态库

Linux之动态库

命令规则 lib 名字 .so 制作步骤 1&#xff09;生成与位置无关的代码&#xff08;生成与位置无关的代码&#xff09; 2&#xff09;将.o打包成共享库&#xff08;动态库&#xff09; 发布和使用共享库 动态库运行原理&#xff1a; 生成动态库&#xff1a; gcc -fPIC -c *.c -…
阅读更多...
linux下源码安装vsftpd-3.0.2

linux下源码安装vsftpd-3.0.2

1&#xff09;在http://vsftpd.beasts.org/网站中查找并下载 vsftpd-3.0.2.tar.gz源码包 2)如果自己的机器上安装有yum可以用yum grouplist | less指令查看以下开发环境&#xff0c;当然这一步不做也行 3&#xff09;拆解源码包 4&#xff09;查看源码包 5&#xff09;编辑…
阅读更多...
Gdb 调试core文件详解

Gdb 调试core文件详解

一&#xff0c;什么是coredump 我们经常听到大家说到程序core掉了&#xff0c;需要定位解决&#xff0c;这里说的大部分是指对应程序由于各种异常或者bug导致在运行过程中异常退出或者中止&#xff0c;并且在满足一定条件下&#xff08;这里为什么说需要满足一定的条件呢&#…
阅读更多...
Windows下编译openssl库

Windows下编译openssl库

1、概述 OpenSSL是一个开放源代码的软件库包&#xff0c;它实现了 SSL&#xff08;Secure SocketLayer&#xff09;和 TLS&#xff08;Transport Layer Security&#xff09;协议&#xff0c;所以应用程序可以使用这个包来进行安全通信&#xff0c;避免窃听&#xff0c;同时确…
阅读更多...
windows环境下C语言socket编程

windows环境下C语言socket编程

最近由于实验需要&#xff0c;要求写一个c程序与java程序通信的软件&#xff0c;为了测试首先写了一个windows环境下c语言的socket&#xff08;tcp&#xff09;通信程序。 首先socket通信的步骤&#xff1a; 图一 socket通信步骤&#xff08;转载) 图二 三次握手协议&…
阅读更多...
Makefile（三）

Makefile（三）

在平时使用中&#xff0c;可以使用以下的makefile来编译单独的代码 src $(wildcard *.c) obj $(patsubst %.c, %.o, $(src))CC gcc CFLAGS -Wall -gall:$(target)$(target):%:%.c$(CC) $< -o $ $(CFLAGS).PHONY: clean all clean:-rm -rf $(target) 使用方法就是make 后…
阅读更多...
数据类型（C++）

数据类型（C++）

不同系统会有不同差异&#xff1a; 类型 位(byte) 范围 char 1 -128—127 or 0 – 255 unsigned char 1 0 – 255 signed int 1 -128—127 int 4 -2^31 – 2^32-1 unsigned int 4 0 – 2^32 signed int 4 -2^31 – 2^32-1 short int 2 2^15 – 2^15-1 …
阅读更多...
dup2函数

dup2函数

将当前系统中的进程信息打印到文件中 命令行&#xff1a;ps aux > out 将ps得到的信息重定向到out文件中 使用dup2文件在程序中完成。 int dup2(int oldfd,int newfd); /*** dup2.c ***/ #include<stdio.h> #include<fcntl.h> #include<unistd.h> #includ…
阅读更多...
内核实现信号捕捉原理

内核实现信号捕捉原理

信号捕捉特性 进程正常运行时&#xff0c;默认PCB中有一个信号屏蔽字&#xff0c;假定为☆&#xff0c;它决定了进程自动屏蔽哪些信号。当注册了某个信号捕捉函数&#xff0c;捕捉到该信号以后&#xff0c;要调用该函数。而该函数有可能执行很长时间&#xff0c;在这期间所屏蔽…
阅读更多...
C++预处理器

C++预处理器

预处理器是一些指令&#xff0c;指示表一起在实际编译之前所需要完成的预处理。 所有的预处理器指令都是以井号(#)开头&#xff0c;只有空格字符可以出现在预指令处理之前。预处理指令不是C语句&#xff0c;所以他们不会以分号(;)结尾。 #define预处理 #define预处理指令用于创…
阅读更多...
Python变量类型

Python变量类型

变量存储在内存中的值&#xff0c;这就意味着在创建变量时会在内存开辟一个空间。 基于变量的数据类型&#xff0c;解析器会分配指定内存&#xff0c;并决定什么数据可以被存储在内存中。 因此变量可以指定不同的数据类型&#xff0c;这些变量可以存储整数、小数、或字符。 变量…
阅读更多...
Python3字符串

Python3字符串

字符串是Python中最常用的数据类型&#xff0c;可以使用单引号或双引号来创建字符串 创建字符串很简单&#xff0c;为变量分配一个值即可。 val1 ‘hello world’ var2 “Runoob” Python访问字符串的值 Python不支持单字符类型&#xff0c;单字符在Python中也是作为 一个字符…
阅读更多...
服务器客户端编程

服务器客户端编程

server 下面通过最简单的客户端/服务器程序的实例来学习socket API。 server.c的作用是从客户端读字符&#xff0c;然后将每个字符转换为大写并回送给客户端。 #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #incl…
阅读更多...
Python3元组

Python3元组

Python的元组与列表相似&#xff0c;不同之处在于元组的元素不能修改 元组使用小括号&#xff0c;列表使用方括号 元组创建很简单&#xff0c;只需要在括号中添加元素&#xff0c;并使用逗号隔开即可。 创建空元组 tup1 (); tup2 (1,) 元组只包含一个元素时&#xff0c;需要在…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023