runtime/pprof: blocking profile time totals are off by several orders of magnitude #19822
Labels
Milestone
Comments
|
Hmmm. Actually, I suppose with enough goroutines all blocked at the same point, the cumulative execution could add up that high. |
|
At a fundamental conceptual level, it's hard to extract signal from noise in the blocking profile model. If your blocking is coming from mutexes, try the mutex profile instead. It does a better job because it knows more about the structure of the blocking. |
gopherbot
pushed a commit
that referenced
this issue
Apr 5, 2017
Updates #15756 Updates #19822 Change-Id: I98b17dcbbfd80e7e164b0523185382175fe2d89b Reviewed-on: https://go-review.googlesource.com/39554 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
lparth
pushed a commit
to lparth/go
that referenced
this issue
Apr 13, 2017
Updates golang#15756 Updates golang#19822 Change-Id: I98b17dcbbfd80e7e164b0523185382175fe2d89b Reviewed-on: https://go-review.googlesource.com/39554 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I ran cmd/compile with the block profiler enabled (see CL 39208), and examined the results with pprof. The header in the pdf says: "Showing nodes accounting for 28.16mins, 99.72% of 28.24mins total". And the biggest node in the pdf showed: "28.16mins (99.72%)". But the total compilation tool less than 5 seconds of real time. Unless I'm holding it wrong, it appears that there's a unit error somewhere in block profiling / pprof.
cc @matloob @rsc
The text was updated successfully, but these errors were encountered: