[go-nuts] Re: memory leak with websocket

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

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] memory leak with websocket

We have a websocket service based on go-socket.io( the socket.io golang implementation), but seems have a memory leak problem. I also have opened a same topic ,but the problem is not be resolved. I also enable the debug.FreeOSMemory, the idle heap now will be released back to OS, but the heap

[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

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

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

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

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

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

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

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

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

We have a simple websocket service based on go-socket.io and have a memory leak problem. We found the memory usage is always increase, the idle heap is not return back to the OS. The heap pprof show that the runtime.goexit took much memory, seems t