0

I'm trying to figure out the bottleneck of my program. Accroding to the benchmark result, the process is blocked at line 485 of runtime/select.go for a considerably long time which is caused by http.(*persistConn).writeLoop, but I have no idea of the root cause.

I've tried to analyse the http operation in my program. but accroding to the flamegraph, my url fetch operations executed by several goroutines parallelly didn't become a significant burden. I have not use "select" in my program, either

Here is the pprof output in the "source" view:

runtime.selectgo
/usr/lib/golang/src/runtime/select.go
Total:    2.75mins   2.75mins (flat, cum) 79.42%

480            .          .             } 
481            .          .             goto retc 
482            .          .            
483            .          .           retc: 
484            .          .             if cas.releasetime > 0 { 
485     2.75mins   2.75mins                 blockevent(cas.releasetime-t0, 1) 
486            .          .             } 
487            .          .             return casi, recvOK 
488            .          .            
489            .          .           sclose: 
490            .          .             // send on closed channel

flamegraph of blocking

I'd like to know the possible cause of this cost or the way to analyze the reason of this cost.

Alex
  • 335
  • 2
  • 12
  • Do you have appropriate timeouts set in all your read and write operations? A blocked write can be multiple things, but the only way to handle it in the write is to timeout. – JimB Aug 28 '19 at 15:29
  • I have no idea about any blocking write operation in my code. The http fetching is issued by DefaultClient from net/http which is said to support asynchornous request from multiple go routines. The neo4j query is issued by the official driver with a underlying lib called seabolt, using the bolt protocol which seems to have no thing to do with http – Alex Aug 30 '19 at 06:24
  • @JimB Is it a fake bottleneck? http.DefaultClient uses a pool of persist connections to handle request, and they stay idle when there is no new request, so they are blocked at the "select" in http.(*persistConn).writeLoop() when they are waiting for new request from pc.writech or closing command from pc.closech. http.(*persistConn).writeLoop() seems to be blocked for a long time because there is no new request? – Alex Aug 30 '19 at 07:49

0 Answers0