Thank you for the very detailed explanation. What I am struggling with is that even if the routines do a little work and go back to sleep (which is probably the case here) - as I increase the number of external clients I would expect there is always a routine ready to run. What I am observing is th
Hi Robert,
First, note that the contention profile for runtime-internal locks doesn't
correctly blame the part of the code that _caused_ delay: with Go 1.22 and
1.23, the call stacks are of (runtime-internal) lock users that
_experienced_ delay. That's https://go.dev/issue/66999, and those odd
Anyone have any idea on the high internal lock time on findRunnable?On Jul 18, 2024, at 10:36 AM, robert engels wrote:Looks like the name was changed to runtimecontentionstacksMuch better now…(pprof) treeShowing nodes accounting for 481.75ms, 100% of 481.75ms totalDropped 39 nodes (cum <= 2.41ms)
Looks like the name was changed to runtimecontentionstacks
Much better now…
(pprof) tree
Showing nodes accounting for 481.75ms, 100% of 481.75ms total
Dropped 39 nodes (cum <= 2.41ms)
--+-
flat flat% sum%cum cu
I found this issue, https://github.com/golang/go/issues/57071 and tried running
with
GODEBUG=profileruntimelocks=1
but it made no difference in the output.
I am using Go 1.22.4 on OSX.
Any ideas how I can determine what is causing this high contention shown below:
(pprof) tree
Showing nodes
