[go-nuts] Re: memory leak with websocket service based on go-socket.io

Finally I fixed the problem. I use the https://github.com/auth0/go-jwt-middleware to auth with JWT. I also open the KeepContext of gorilla mux router to true for that can get the jwt token of request from the goriila context. When I get the jwt token, will clear the request context (via contex

[go-nuts] Re: memory leak with websocket service based on go-socket.io

Whatever, thanks so much. 在 2016年9月6日星期二 UTC+8下午5:54:34，Dave Cheney写道： > > I'm sorry. I cannot help you, I'm probably wrong about the goroutines > holding on to webaockets. Perhaps one of the libraries you use has a memory > leak bug. -- You received this message because you are subscribed t

[go-nuts] Re: memory leak with websocket service based on go-socket.io

I'm sorry. I cannot help you, I'm probably wrong about the goroutines holding on to webaockets. Perhaps one of the libraries you use has a memory leak bug. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop

[go-nuts] Re: memory leak with websocket service based on go-socket.io

When user refresh the page, the old websocket conn will be closed and a new one created. I do not understand "If the websocket never disconnects, then the goroutine will pin all memory it is using." The websocekt conn block on read, why will pin all memory? 在 2016年9月6日星期二 UTC+8下午5:22:39，Da

[go-nuts] Re: memory leak with websocket service based on go-socket.io

You have 4601 goroutines blocked on reading from the websocket goroutine profile: total 4583 1526 @ 0x42d77a 0x42806b 0x4277c9 0x67ffb8 0x680024 0x681861 0x6924e0 0x5b2e5c 0x5b34bc 0x7bc06d 0x7bc1b6 0x7bd237 0x7a2d94 0x45da11 # 0x4277c8net.runtime_pollWait+0x58

[go-nuts] Re: memory leak with websocket service based on go-socket.io

I can make sure that the goroutine is exited, because the goroutine count is stable but the heap count is always increase. You can see more detail pprof from https://comet.shiyanlou.com/debug/pprof/. 在 2016年9月6日星期二 UTC+8下午5:05:05，Dave Cheney写道： > > Are you sure that goroutines are exiting? You

[go-nuts] Re: memory leak with websocket service based on go-socket.io

Are you sure that goroutines are exiting? You can check this in the /debug/pprof handler. It will tell you how many goroutines are currently running. On Tuesday, 6 September 2016 18:49:29 UTC+10, aide...@gmail.com wrote: > > I think > https://gist.github.com/aiden0z/b8cf00953e81f778bd584fa2ff7e

[go-nuts] Re: memory leak with websocket service based on go-socket.io

I think https://gist.github.com/aiden0z/b8cf00953e81f778bd584fa2ff7eaae7#file-server-go-L268 error is not the core problem. The error is ignored because the go-socket.io no error returned, see https://github.com/googollee/go-socket.io/blob/master/server.go#L91. go 1.6 and 1.7 I have tried,

[go-nuts] Re: memory leak with websocket service based on go-socket.io

This error handling looks wrong, https://gist.github.com/aiden0z/b8cf00953e81f778bd584fa2ff7eaae7#file-server-go-L268 Any error from socketio is ignored, and the method always succeeds unconditionally. Also, which version of Go are you using ? On Tuesday, 6 September 2016 18:07:42 UTC+10, aide

[go-nuts] Re: memory leak with websocket service based on go-socket.io

I have restart the the websocket service, and collect new callgraph. 1. in-use heap callgraph 2. heap alloc callgraph

[go-nuts] Re: memory leak with websocket service based on go-socket.io

Also, heap released will not grow until you stop the memory leak and enough of the heap remains idle for more than 10 minutes. -- 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, sen

[go-nuts] Re: memory leak with websocket service based on go-socket.io

Are you sure that goroutines are exiting? You can check this in the /debug/pprof handler. It will tell you how many goroutines are currently running. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop recei

[go-nuts] Re: memory leak with websocket service based on go-socket.io

I think your program is leaking memory somewhere else. Is the source of your application avaiable? Can you please share a graph of the -alloc_objects profile -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and sto

[go-nuts] Re: memory leak with websocket service based on go-socket.io

I has installed the pprof handler and also opened the gc debug. The HeapSys in /debug/pprof/heap page is aways increase, the HeapReleased aways is 0. The gc debug log show that the scvg# is not release any memory. If the runtime.goexit be called, the goroutine will be return. But why the memo

[go-nuts] Re: memory leak with websocket service based on go-socket.io

Your operating system may not be reporting memory correctly. To get the accurate report of the memory that your go process uses http://talks.godoc.org/github.com/davecheney/presentations/seven.slide#23 Install the pprof handler, and scroll to the bottom of go tool pprof http://localhost:3999/

[go-nuts] Re: memory leak with websocket service based on go-socket.io

Build with -race flag report nothing. Something is interesting is that in the dev env the gc will release the memory, but in product env the memory seems is not release to OS. 在 2016年9月6日星期二 UTC+8下午2:05:38，Dave Cheney写道： > > runtime.goexit is the bottom most stack frame of any running gorout

[go-nuts] Re: memory leak with websocket service based on go-socket.io

runtime.goexit is the bottom most stack frame of any running goroutine. When the caller of runtime.goexit returns, this function will clean up the goroutine. If you are not leaking goroutines, then your application must be keeping too much memory live, possibly in a shared map. It's probably

[go-nuts] Re: memory leak with websocket service based on go-socket.io

The number of goroutines is normal., but the memory continue increase. I did not understand why the runtime.goexit took so many memory. 在 2016年9月6日星期二 UTC+8上午11:07:42，Dave Cheney写道： > > It looks like your application is using 4.5gb of ram. Check the number of > sockets and goroutines you have r