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/debug/pprof/heap The memory statistics will be reported at the bottom # HeapSys = 4882432 ^ this is the number of bytes your operation system has given to the Go process. On Tuesday, 6 September 2016 16:37:45 UTC+10, aide...@gmail.com wrote: > > 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 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 also a good idea to build your application with the -race >> detector and fix any issues that it repors. >> >> On Tuesday, 6 September 2016 15:56:04 UTC+10, aide...@gmail.com wrote: >>> >>> 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 running. If there are no timeouts then >>>> the goroutines could remain alive pinning a lot of memory. >>> >>> -- 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. For more options, visit https://groups.google.com/d/optout.
