pprof -call_tree 有什么作用？

Question

go tool pprof有一个-call_tree选项，根据-help，应该“创建一个上下文相关的调用树”。但是，pprof -tree在 CPU 配置文件上，无论有无此选项，我都能得到完全相同的输出。它看起来像这样（一个代表节点）：

      flat  flat%   sum%        cum   cum%   calls calls% + context          

----------------------------------------------------------+-------------

                                             0.07s 35.00% |   google.golang.org/grpc/internal/transport.(*http2Server).operateHeaders

                                             0.04s 20.00% |   golang.org/x/net/http2.(*Framer).readMetaFrame

                                             0.02s 10.00% |   github.com/Shopify/sarama.(*FetchResponse).decode

     0.06s  0.79% 51.18%      0.20s  2.63%                | runtime.mapassign_faststr

                                             0.05s 25.00% |   runtime.newobject (inline)

                                             0.03s 15.00% |   aeshashbody

                                             0.03s 15.00% |   runtime.mallocgc

这显然不是一棵树，尤其是因为它显示了在 HTTP/2 下的 Sarama——从 Kafka 消费（通过 Sarama）和提供 HTTP/2 是这个过程同时执行的两个独立的事情。

为什么不-call_tree影响这个输出-tree？一般来说，-call_tree做什么？

额外学分

我上面显示的输出节点的确切含义是什么？这是否意味着包含 35% 的样本mapassign_faststr也包含operateHeaders在堆栈的某个位置，而 10% 包含decode？下面的行呢，例如mallocgc？

我可以阅读哪些文件来回答上述问题？

Answer 1

为什么 -call_tree 不影响 -tree 的输出我认为该-call_tree选项不会改变输出-tree的输出实际上不是一棵树，它输出树的节点（更多关于这在额外的信用部分）。一般来说，-call_tree 是做什么的？当您查看使用-png标志生成的图像时，您会看到不同之处，没有-call_tree标志：和使用-call_tree标志：因此，pprof 没有尝试创建 1 个调用树，而是尝试根据上下文创建单独的树。在我的情况下（将列出它们，因为图像上的文本不可读）根是：testing.(*B).launch（基准/测试框架）runtime.gcBgMarkWorker（运行时 GC 的一部分）runtime.bgsweep（运行时 GC 的一部分）runtime.mcall（运行时调度程序的一部分）runtime.morestack（与堆栈有关:)）在非-call_tree图像中，这些节点仍然存在，但是从中间树开始，就好像我们的代码直接调用这些背景处理一样。基本上，该选项的作用是删除/隐藏函数之间的不频繁调用，因此您最终会为每组经常相互调用的函数生成一棵树。我没有对此进行测试，但我想 pprof 也会对用户代码进行这种上下文感知树分离。总而言之，它返回一个主观上更具可读性的树，或者至少是一个更相关的树。我上面显示的输出节点的确切含义是什么？该-tree选项尝试输出树，如图所示。但是由于它是文本输出，它一次显示树的 1 个节点，context列中的非缩进行是当前节点，上面的行是调用当前节点的节点，下面的行是调用当前节点的节点（图中的箭头）。这calls%是传入或传出边缘的“权重”，因此实际上是来自函数或函数调用的百分比。