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？我可以閱讀哪些文件來回答上述問題？
1 回答
犯罪嫌疑人X
TA貢獻2080條經驗 獲得超4個贊
為什么 -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%是傳入或傳出邊緣的“權重”，因此實際上是來自函數或函數調用的百分比。
- 1 回答
- 0 關注
- 121 瀏覽
添加回答
舉報
0/150
提交
取消