Linux使用perf分析CPU占用情况的方法步骤

目录

• 1. 如何使用perf工具
• 1.1 perf安装
• 1.2 首次使用perf报错
• 1.3 添加测试程序
• 1.4 编译并执行指令生成perf.data文件
• 1.5 添加-g选项能查看call graph调用信息
• 1.6 查看perf.data
• 1.7 perf工作流
• 1.8 sudo perf record -F 99 -p 2512 -g – sleep 60
• 2. 如何生成火焰图
• 2.1 安装火焰图生成工具
• 2.2 生成和创建火焰图的步骤
• 2.3 火焰图的含义
• 2.4 生成"红/蓝差分火焰图"示例
• 3. 使用perf分析节点CPU占比

1. 如何使用perf工具

1.1 perf安装

参考perf工具安装和使用

perf安装命令：

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 添加测试程序

新建并添加测试程序如下，输入代码

touch main.cpp
vim main.cpp

#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文件

编译测试程序

g++ main.cpp -o main

生成perf.data

sudo perf record ./main

1.5 添加-g选项能查看call graph调用信息

添加-g选项查看调用信息

sudo perf record -g ./main

1.6 查看perf.data

生成热点函数占用CPU的比例

perf report

可以看到, 程序中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 recordjs获得的样本数量也会越多，分析结果会更加精细，但采样会使程序的运行变慢，因此需要根据具体情况选择合适的采样频率; 默认频率4000Hz

• -p: 指定进程号, 对某一进程进行分析
• -g: 表示记录调用栈, 拿到程序的call graph信息
• --sleep 60: 表示对进程持续分析60s

2. 如何生成火焰图

2.1 安装火焰图生成工具

Flame Graph工程实现了一套生成火焰php图的脚本, 直接clone下来使用

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轴是任务时间轴), “红/蓝差分火焰图”, 红蓝差分火焰图可以用来对比分android析两次修改的性能差异, 红色表示上升, 蓝色表示下降, 由此来寻找根因; 此外还有"Memory Flame Graphs"(检测内存占用量增加的原因), “Off-CPU Flame Graphs”(不在CPU上运行的时间,如I/O时间等), “Hot/Cold Flame Graphs”(CPU和非CPU结合,显示所有线程的运行时间)

2.4 生成"红/蓝差分火焰图"示例

修改源程序

#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;
}

重新编译执行

g++ main.cpp -o main
sudo perf record -g ./main		# 生成新的perf.data

折叠堆栈

perf script -i perf.data &> perf.unfold		# 生成新的perf.unfold
./FlameGraph/FlameGraph/stackcollapse-perf.pl perf.unfold &javascript> perf.folded1

生成火焰图

./FlameGraph/FlameGraph/flamegraph.pl perf.folded1 > perf2.svg

以perf.folded为基准,生成差分火焰图

./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 # 动态链接库管理, 让不同目录下的动态链接库为系统所共享
• 或者试下 ldconf编程ig 然后 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进行采样

top		# 查看程序PID = 228

perf record -p 228 -g		# 生成perf.data, Ctrl + C结束录制

perf report				# 可正常读取

生成火焰图

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占用

以上就是Linux使用perf分析CPU占用情况的方法步骤的详细内容，更多关于Linux perf分析CPU的资料请关注编程客栈(www.devze.com)其它相关文章！