使用火焰图隐藏功能提高绘制精度

最新推荐文章于 2021-09-12 16:08:19 发布

红烧的威化饼

最新推荐文章于 2021-09-12 16:08:19 发布

阅读量215

点赞数

分类专栏：技术文档

原文链接：https://mp.weixin.qq.com/s/NVRC2UzSKKtvuFrU_Js9-w

版权

技术文档专栏收录该内容

1 篇文章 0 订阅

订阅专栏

使用火焰图隐藏功能提高绘制精度

这篇文章是我写的，于2020年6月8日首发于 [Linux阅马场] 公众号。传送门： https://mp.weixin.qq.com/s/NVRC2UzSKKtvuFrU_Js9-w

2020年6月18日转载于我自己的github blog。
传送门： https://hongweiqin.github.io/blog/posts/2020/20200618/

以下为正文：

由于CPU能耗优化的原因，火焰图有时并不准确。为此，我们来做一个小实验。

1.小实验

这是一个简单C程序，其实就是一个死循环，如下：

#include<stdio.h>
int globalv;
void dosth()
{
	globalv++;
}
int main()
{
	globalv = 0;
	for(;;)
		dosth();
	return 0;
}

编译后可执行程序名为func。接下来我开了两个终端，分别使用taskset将func运行在CPU0和CPU1上:

taskset 0x1 ./func
taskset 0x2 ./func

然后使用bcc+flamegraph绘制火焰图：

/bcc/profile -I -F 99 -daf 10 > out.profile
/mnt/sdb/FlameGraph/flamegraph.pl < out.profile > out.svg

得到的火焰图：

flame1

我的测试环境是Qemu/KVM, 32核。

我们可以看到，火焰图显示，func程序占用了近四分之一的CPU时间。
但是由于我们把func绑定在CPU0和1上执行，根据小学数学我们应该可以计算出来func最多占用2/32=6.25%的时间。

是不是有点不对？

2.原因

由于Linux会对CPU进行能耗优化，在低负载的时候，CPU并不是满负荷工作（降频），因此对于Idle的CPU，bcc的采样数会减少，从而导致总采样数减少。我们可以看到，我们的采样频率是99个样本/(min*CPU)。运行了10s，那么总的样本数应该大约为99*10*32=31680。而实际的总采样数只有8197。分母小了，自然func占用的CPU时间比例增加了。

3.解决办法

当然，我们可以修改CPUfreq强制让所有满负荷工作。但是这样一来麻烦，二来我的测试环境是虚拟机，修改起来更加麻烦。我们希望用一个简单的方法解决。

这就要提到flamegraph的隐藏功能了。为什么叫隐藏功能？因为如果你简单地./flamegraph.pl --help他不会告诉你这个用法。但是实际上他已经实现了这个功能，语法是：

./flamegraph.pl --total=N < out.profile > out2.svg

其中N为用户规定的总采样数。在我们的示例中，应该是31680。这样，我们绘制出来的火焰图是这个样子的：
flame2

嗯，的确有点丑，但是6.26%才是func真正消耗了的CPU时间比例。

4.关于CPU时间准确性的讨论

怎样才算是绘制了准确的火焰图呢？

考虑如下情形，如果CPU1满负荷运转执行func110秒钟，而CPU2半负荷运转执行func25秒钟，剩下5s是idle。

算法1：
:实际上func1和func2一起是占用了15s的CPU时间。
根据计算，func占用的时间占总时间的15s/(10s*32)=4.69%。

算法2：
如果按照上面第三节所描述的方法绘制火焰图，采样结果应该是func1有大约990个样本，func2有大约990/2/2=248个样本，绘制出来的火焰图func占比为(990+248)/31680=3.9%

两者不相等！
笔者认为，原因在于二者算法所获结果的含义不同。算法1计算出来的是在这种运行情形下实际func的执行时间占比。而算法2计算出来（或者说绘制出来）的是在CPU满负荷运转下func的CPU时间占比。
从现实来看，不同背景负载，不同情形下同一个workload的运行时间可能不同。当系统负载加重时，Linux会自动控制CPUfreq将CPU频率增加。单单查看在某一个情形下workload的CPU执行时间意义有限。但是，对于一个workload而言，他所需要占用的计算资源量往往是相同的。
因此，从程序优化角度而言，采用第三节所描述的方法计算CPU满负载下应用程序的时间占比对于我们优化代码更具有指导性意义。