-
Notifications
You must be signed in to change notification settings - Fork 18k
proposal: runtime/metrics: add mutex slow path counters #54236
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
cc @golang/runtime @mknyszek |
I'm certainly not opposed! If you have a concrete implementation in mind and want to send a patch, I'm happy to review the changes. Otherwise I'll try to get around to it this cycle, but no promises. I was planning on adding some GC CPU counters this dev cycle, along with maybe a few more scheduling metrics. |
Also, I think there might actually be another issue about this? #49881 I also believe there was an internal feature request for this, too. Seems like a good idea. :) |
Just to be concrete, if I understand correctly, a mutex profile would work here, but you are looking for a general "contention level/rate" counter that can be easily monitored via a monitoring system, which could alert you that you may want to look at an actual profile. I also think that sounds reasonable and useful. |
Closing as duplicate of #49881, which seems to be slated for Go 1.20. |
Duplicate of #49881 |
We modified the runtime & sync package a bit to add counters when a
sync.Mutex.Lock
andsync.RWMutex.RLock
call go into their slow paths:tailscale@effe2d1 (corp CLA on file; same license as Go)
That's a bit of hack (adding some global variables to the sync package) but it gets us information easily.
Would the runtime team be interested in adding this sort of information more officially via the
runtime/metrics
package?We know about the "block" and "mutex" pprof types, but they're a bit more tedious to use to just get a counter.
Our use case is: we have a server that with some very hot mutexes and we want to high level metric showing how happy it is that'll become unhappy looking if people add too much code in the critical section.
The text was updated successfully, but these errors were encountered: