runtime: program takes more OS threads than expected #1480
Labels
Milestone
Comments
|
Owner changed to builder@golang.org. |
I looked into this. I think this is expected behavior.
There will always be a few extra threads because you've got different goroutines running
system calls, and the runtime creates new threads as necessary to avoid blocking the
entire program just because a few goroutines are executing system calls.
You can profile where the threads are coming from by running this variant of your
program:
package main
import (
"log"
"net/http"
_ "net/http/pprof"
)
func handler(wr http.ResponseWriter, req *http.Request) {
wr.Write([]byte("Ok!\n"))
}
func main() {
http.HandleFunc("/", handler)
err := http.ListenAndServe(":8080", nil)
if err != nil {
log.Fatalln("ListenAndServe:", err)
}
}
after sieging it, run
go tool pprof http://localhost:8081/debug/pprof/thread
and at the (pprof) prompt, run web. It will show the call stacks
that led to the creation of new threads. Especially if you see
the thread count growing without bound, this will help you figure
out why (and that would be a bug; please report it). But 8 threads
seems fine.
Status changed to WorkingAsIntended. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
from ziutek <ziutek@lnet.pl> to golang-nuts <golang-nuts@googlegroups.com> date Fri, Feb 4, 2011 at 09:23 subject [go-nuts] Re: How GOMAXPROCS is used by current 8g implementation? I wrote simple test using http package: package main import ( "log" "http" ) func handler(wr http.ResponseWriter, req *http.Request) { wr.Write([]byte("Ok!\n")) } func main() { err := http.ListenAndServe(":8080", http.HandlerFunc(handler)) if err != nil { log.Fatalln("ListenAndServe:", err) } } Then compile it and run: $ 8g test.go && 8l -o test test.8 $ GOMAXPROC=2 ./test There is output from ps -eL |grep test 3176 3176 pts/0 00:00:00 test 3176 3177 pts/0 00:00:00 test Next I use curl to get something from this application: $ curl 127.0.0.1:8080 Ok! $ curl 127.0.0.1:8080 Ok! And ps -eL: 3176 3176 pts/0 00:00:00 test 3176 3177 pts/0 00:00:00 test Next I use siege with 10 concurrent simulated users: $ siege 127.0.0.1:8080 -c10 -d0 -t10s ** SIEGE 2.70 ** Preparing 10 concurrent users for battle. The server is now under siege... Lifting the server siege. done. Transactions: 11791 hits Availability: 100.00 % Elapsed time: 9.07 secs Data transferred: 0.04 MB Response time: 0.01 secs Transaction rate: 1300.00 trans/sec Throughput: 0.00 MB/sec Concurrency: 9.85 Successful transactions: 11792 Failed transactions: 0 Longest transaction: 0.03 Shortest transaction: 0.00 And ps -eL: 3176 3176 pts/0 00:00:00 test 3176 3177 pts/0 00:00:00 test 3176 3260 pts/0 00:00:01 test 3176 3261 pts/0 00:00:00 test 3176 3262 pts/0 00:00:01 test 3176 3263 pts/0 00:00:01 test 3176 3264 pts/0 00:00:01 test 3176 3265 pts/0 00:00:01 test there is 8 persistent threads. This number of threads is constant even if I use siege with 100 concurrent users. Is this the expected behavior? Maybe it is related to my 36 threads "problem" (it isn't any problem for me if the number of threads will not increase in time).The text was updated successfully, but these errors were encountered: