> > > For me, this looks like the program is merely idling, and what you're > observing is reading current time by the scheduler implemented by the Go > runtime. > I didn't try it. The environment located in customer's data center, not allowed to try this kind of things on it.
> > [...] > > 1. Any body know the reason of the problem? > > I'm inclined to think that you're merely facing some deadlock or similar > condition which precludes your normal Go code from doing useful progress > while > the runtime itself is OK. > > I agree with this, too. But the program didn't respond to any pprof interaction (We implemented a pprof server using domain socket), so I can not get goroutine information. > > 2. What can I do to get more information if this problem happened > again? > > Do the following: > > - Have a way to collect whatever the process is writing to its stderr. > - When the process wedges in the same way, send it SIGQUIT or SIGABRT so > that > it dumps the stacks of all the active goroutines to the stderr and > exits. > > I will try this next time. > If that service handles HTTP requests, you might enable the handlers of the > core debug/pprof package and when the process it apparently wedged > navigate to > its /debug/pprof/goroutine?debug=2 (unless you have grafted the root of > those endpoints somewhere else) to have the stacks sent in the response. > > As I mentioned above, pprof is enabled by default, but the program ceased to respond to anything. Thanks very much. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAF_Sdb9imBONz%3DYL4%3DUQ9aqTSwLQT%3DN4eL7_g5AKAEdPsjGrOQ%40mail.gmail.com.
