2021-06-11

Posted 2021-06-27 造夢先森

一、perf获取数据
1)对整体CPU分析： perf top
2)对指定进程分析cpu占用： perf top -p pid
3)对指定进程设置采样时间和采样频率：perf record -g -F 99 -p “pid” – sleep 60 //持续采样时间60s,采样频率99次/s

二、数据获取
./perf report //查看生产的数据

三、如果觉得可视化效果不好，可以用火焰图进一步展示
1)perf script -i perf.data >perf.unfold //将生成数据解析
2)./stackcollapse-perf.pl perf.unfold > perf.folded //利用FlameGraph工具折叠符号
3)./flamegraph.pl perf.folded > perf.svg //生成svg图
或
perf script | ./stackcollapse-perf.pl | ./flamegraph.pl > process.svg

工具获取：来自火焰图项目地址：git clone
https://github.com/brendangregg/FlameGraph.git

perf有时给出的callchain是错误的，这里简单说一下原因及解决方法。

callchain时指函数的调用路径。通常我们也把它称为call trace。

很多同学在使用perf看热点函数的调用路径时，都发现perf给出的callchain是一堆混乱的地址，或者给出的callchain根本不对。

我们先来解释一下perf获得callchain的方法：如果我们需要取callchain，内核就会在采样时保存内核栈以及用户栈中的各个函数的返回地址。对函数返回地址的获取以及对整个栈的遍历，可以通过栈底指针实现。而这个栈底指针，通常会保存在EBP寄存器中。内核也正是通过EBP获得栈底指针的。

但是，当我们利用’-O’以上的优化选项编译程序时，GCC会将栈底指针优化掉，并把EBP作为一个通用寄存器。此时，我们从EBP中读到的值就不再是栈底指针了。perf与内核获得的callchain就是错误的。

为了解决这个问题，我们建议大家在编译应用程序的调试版本时加上编译参数“-fno-omit-frame-pointer”。该参数使得GCC在优化程序时保留EBP的栈底指针功能。也只有在这种情况下，我们获得的callchain才是正确的。

对于优化选项“-fomit-frame-pointer”产生的优化加速比，我们后面会给出具体的说明和实验数据。但目前猜测，该选项带来的优化效果不会非常大。它在一定程度上能够减少binary文件的footprint，并带来一定的性能提升。

在最新版本的内核中，已经支持了利用libunwind获得callchain的功能。在libunwind的支持下，可以不通过EBP来获得应用程序的callchain。此时，我们可以通过如下命令执行perf：

#sudo perf top -G dwarf
#sudo perf record -g dwarf