runtime: reduce scheduling contention for large $GOMAXPROCS #2933
Labels
Comments
Can't generate html on server box, I attached .pdf Attachments:
|
Try 32 or 48 anyway; see if it helps. The problem is that the scheduler is working very hard to keep at most 16 goroutines running through user space at a time, so as one goroutine goes to sleep reading from a network connection it must wake up another goroutine whose turn it is now to run. If there were less contention (by having more slots) then you wouldn't see all this scheduling activity. Russ |
The scheduler needs some work in this regard. That will happen after Go 1. Labels changed: added priority-later, removed priority-triage. Owner changed to builder@golang.org. Status changed to Accepted. |
|
Owner changed to @dvyukov. |
|
Comment 14 by vadim@percona.com: I wonder what is the status of this problem. Will it be fixed in 1.1? Without it I can't use Go for high concurrent workloads. |
Download it and see: https://code.google.com/p/go/downloads/list?can=2&q=go1.1 Much scheduler stuff was changed. |
|
I am having a similar problem with the latest stable release of go. Each query coming in via a tcp packet command is using around 24% cpu (spikes at the query) then just drops back to 0% after the query. But that is really odd. |
|
@majimboo please file a new issue with necessary details: what behavior you expect, what behavior you see, go/os/hardware details and reproduction instructions. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
by apachephp:
I run benchmark against MySQL, there are multiple threads (goroutine) connecting to MySQL and running short queries. In this scenario go application uses most CPU resources, and from profiling it seems that is related to Mutex usage in Net Read Profiling: (pprof) top20 -cum Total: 528260 samples 0 0.0% 0.0% 412464 78.1% runtime.initdone 22 0.0% 0.0% 401608 76.0% main.sleepy 22 0.0% 0.0% 400454 75.8% main.runQuery 587 0.1% 0.1% 393491 74.5% github%2ecom/Philio/GoMySQL..getResult 1155 0.2% 0.3% 370480 70.1% github%2ecom/Philio/GoMySQL..readPacket 26 0.0% 0.3% 356381 67.5% github%2ecom/Philio/GoMySQL..StoreResult 136 0.0% 0.4% 356135 67.4% github%2ecom/Philio/GoMySQL..getAllRows 138 0.0% 0.4% 356026 67.4% github%2ecom/Philio/GoMySQL..getRow 371 0.1% 0.5% 329772 62.4% io.ReadFull 801 0.2% 0.6% 329470 62.4% io.ReadAtLeast 1627 0.3% 0.9% 328820 62.2% net..Read 317879 60.2% 61.1% 317879 60.2% runtime.futex 23042 4.4% 65.5% 297638 56.3% syscall.Syscall 524 0.1% 65.6% 293808 55.6% syscall.Read 15311 2.9% 68.5% 243751 46.1% runtime.entersyscall 973 0.2% 68.6% 236760 44.8% github%2ecom/Philio/GoMySQL..readNumber 88 0.0% 68.7% 182475 34.5% futexwakeup 316 0.1% 68.7% 179999 34.1% schedunlock 166 0.0% 68.8% 162654 30.8% runtime.unlock 168 0.0% 68.8% 162546 30.8% futexunlock Is there way to use mutex for shorter period of time in such scenario ? With such problem I can't use go application for benchmarking, as it consumes for CPU than MySQLThe text was updated successfully, but these errors were encountered: