1. 如何使用perf工具
1.1 perf安装
参考perf工具安装和使用
perf安装命令：
|
1
2
3
4
|
sudo apt-get install linux-tools-$(uname -r) linux-tools-generic -y
sudo apt-get install linux-tools-$(uname -r) linux-tools-generic -y --fix-missing
perf -v # 查看perf版本
|
1.2 首次使用perf报错
No permission to enable cycles: u event
解决方法：直接修改 /proc/sys/kernel/perf_event_paranoid，按照报错提示修改为 -1
如果是docker容器环境提示 read only file system, 新建容器的时候应该添加 privileged=true 赋予权限
1.3 添加测试程序
新建并添加测试程序如下，输入代码
|
1
2
|
touch main.cpp
vim main.cpp
|
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
|
#include <iostream>
using namespace std;
void delay()
{
int i,j;
for(i = 0; i < 1000000; i++)
j=i;
}
void function_1()
{
int i;
for(i=0 ; i < 10; i++)
delay();
}
void function_2()
{
int i;
for(i = 0; i< 30; i++)
delay();
}
int main(void)
{
std::cout << "begin: " << std::endl;
function_1();
function_2();
std::cout << "end!" << std::endl;
}
|
1.4 编译并执行指令生成perf.data文件
编译测试程序
生成perf.data
|
1
|
sudo perf record ./main
|
1.5 添加-g选项能查看call graph调用信息
添加-g选项查看调用信息
|
1
|
sudo perf record -g ./main
|
1.6 查看perf.data
生成热点函数占用CPU的比例
可以看到, 程序中main函数总体CPU资源占比(CPU时间片)97.85%, 其中delay函数占比97.59%, function_1和function_2的占比占比近7:3
1.7 perf工作流
1.8 sudo perf record -F 99 -p 2512 -g – sleep 60
- record: 表示采集系统事件，没有采用-e执行采集事件，则默认采用CPU时钟周期
- -F: 指定采样频率, 可以设置99, 1000等等, -F 99表示每秒采样99次, 如果99次都是同一函数, 说明CPU在这1s内都在执行这一函数, 可能存在性能问题. 频率越高，perf record获得的样本数量也会越多，分析结果会更加精细，但采样会使程序的运行变慢，因此需要根据具体情况选择合适的采样频率; 默认频率4000Hz
- -p: 指定进程号, 对某一进程进行分析
- -g: 表示记录调用栈, 拿到程序的call graph信息
- --sleep 60: 表示对进程持续分析60s
2. 如何生成火焰图
2.1 安装火焰图生成工具
Flame Graph工程实现了一套生成火焰图的脚本, 直接clone下来使用
|
1
|
git clone https://github.com/brendangregg/FlameGraph.git
|
该文件夹下有很多perf语言脚本, 可完成不同堆栈分析
2.2 生成和创建火焰图的步骤
捕获堆栈: perf script -i perf.data &> perf.unfold
折叠堆栈: ./FlameGraph/FlameGraph/stackcollapse-perf.pl perf.unfold &> perf.folded
生成火焰图: ./FlameGraph/FlameGraph/flamegraph.pl perf.folded > perf.svg
各个步骤的含义：
- 捕获堆栈: 可以使用 perf、systemtap、dtrace 等工具抓取程序的运行堆栈
- 折叠堆栈: 对捕获的堆栈信息进行分析组合, 将重复的堆栈累计在一起, 从而体现出负载和关键路径, 由FlameGraph的stackcollapse程序生成, 注意程序路径
- 生成火焰图: 分析由stackcollapse输出的堆栈信息的火焰图, 执行完后生成.svg图片
2.3 火焰图的含义
y轴表示调用栈，每一层都是一个函数。调用栈越深，火焰就越高，顶部就是正在执行的函数，下方都是它的父函数
x轴表示抽样数，如果一个函数在x轴占据的宽度越宽，就表示它被抽到的次数多，即执行的时间占比越大。注意，x轴不代表时间，而是所有的调用栈合并后，按字母顺序排列的
颜色无特殊含义, 因为火焰图表示CPU的繁忙程度, 所以一般选择暖色调
火焰图就是看顶层的哪个函数占据的宽度最大。只要有"平顶"，就表示该函数可能存在性能问题
鼠标悬浮: (浏览器打开.svg图片)可显示函数名, 抽样抽中的次数, 占总抽样次数的百分比
点击放大: 点击某一层，该层会占据所有宽度，显示详细信息，再点击左上角ResetZoom可恢复
查找: Ctrl + F, 高亮显示查找的函数
火焰图的缺陷: 调用栈可能不完整, 当调用栈过深时，某些系统只返回前面的一部分（比如前10层）; 函数名可能缺失, 有些函数没有名字，编译器只用内存地址来表示（比如匿名函数）, 有可能是编译器优化等级过高
FlameGraph我们习惯称之为"CPU火焰图", 还有"浏览器火焰图"(x轴是任务时间轴), “红/蓝差分火焰图”, 红蓝差分火焰图可以用来对比分析两次修改的性能差异, 红色表示上升, 蓝色表示下降, 由此来寻找根因; 此外还有"Memory Flame Graphs"(检测内存占用量增加的原因), “Off-CPU Flame Graphs”(不在CPU上运行的时间,如I/O时间等), “Hot/Cold Flame Graphs”(CPU和非CPU结合,显示所有线程的运行时间)
2.4 生成"红/蓝差分火焰图"示例
修改源程序
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
|
#include <iostream>
using namespace std;
void delay()
{
int i,j;
for(i = 0; i < 1000000; i++)
j=i;
}
void function_1()
{
int i;
for(i=0 ; i < 20; i++)
delay();
}
void function_2()
{
int i;
for(i = 0; i< 20; i++)
delay();
}
int main(void)
{
std::cout << "begin: " << std::endl;
function_1();
function_2();
std::cout << "end!" << std::endl;
}
|
重新编译执行
|
1
2
|
g++ main.cpp -o main
sudo perf record -g ./main # 生成新的perf.data
|
折叠堆栈
|
1
2
|
perf script -i perf.data &> perf.unfold # 生成新的perf.unfold
./FlameGraph/FlameGraph/stackcollapse-perf.pl perf.unfold &> perf.folded1
|
生成火焰图
|
1
|
./FlameGraph/FlameGraph/flamegraph.pl perf.folded1 > perf2.svg
|
以perf.folded为基准,生成差分火焰图
|
1
|
./FlameGraph/FlameGraph/difffolded.pl perf.folded perf.folded1 | ./FlameGraph/FlameGraph/flamegraph.pl > diff.svg
|
浏览器打开diff.svg
红色部分表示function_1中delay耗时增加了, 蓝色部分表示function_2中delay耗时减少了, 和我们修改的预期是一样的
3. 使用perf分析节点CPU占比
执行报错1：sudo perf record -g ./可执行文件, 执行失败。节点编译完成后报错找不到
error while loading shared libraries: liblibstatistics_collector.so
解决方法：搜索发现liblibstatistics_collector.so存在, 但通过export添加路径后不生效
- export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/so_path 执行后不管用
- sudo ldconfig # 动态链接库管理, 让不同目录下的动态链接库为系统所共享
- 或者试下 ldconfig 然后 perf record -g ./可执行文件, 不要加sudo
- 执行后生效
执行报错2：上一步生成的perf.data执行perf report提示文件size field is 0
data size field is 0 which is unexpected
原因分析：看下来是perf record -g ./可执行文件的形式没有正确生成perf.data, 单独执行perf record进行采样
|
1
2
3
4
5
|
top # 查看程序PID = 228
perf record -p 228 -g # 生成perf.data, Ctrl + C结束录制
perf report # 可正常读取
|
生成火焰图
|
1
2
3
4
5
|
perf script -i perf.data &> perf.unfold # 捕获堆栈
./FlameGraph/FlameGraph/stackcollapse-perf.pl perf.unfold &> perf.folded # 折叠堆栈
./FlameGraph/FlameGraph/flamegraph.pl perf.folded > perf.svg # 生成火焰图
|
浏览器打开.svg图片
ros2的CPU占用，播包5min
ros1的CPU占用，播包5min
对比结论：
- 节点总体CPU占用在102%
- 长时播包测试可知，节点的CPU占用主要来自std::thread::State_impl占74.51%，其中主程序25%+多线程相关45%
- 多线程相关的45%分析
- 对比ros1的CPU占用，在ros2中节点的CPU占用高只是运行机制的差异
- 对多线程管理占用的45%的CPU，包含除主程序外的多个任务：不同topic消息队列同步访问，消息转proto，消息收发同步；线程同步统计节点掉线信息；线程同步维护节点状态信息等
- 此外，在添加多线程同步前，这部分的CPU还是1-2核占满，线程间阻塞同步的方式降低了一个核以上的CPU占用，但线程同步还存在一部分的CPU占用
