Hey Mariappan, >From my experience, there are several possible options:
I believe you can use GOTRACEBACK=crash env variable (or its equivalent in the runtime/debug package in the std) to get a coredump on the crash. See this old post from JBD [1], that explored this. If you clearly observe, that the application "leaks" its memory (or it "leaks goroutines") via the metrics — simple by looking at the trends in the app's memory usage — you may collect several pprof files (heap and goroutines), with some interval. Then explore the diff between the two profiles with pprof tool's diff option. To help automating this, the continuous profiling became a fairly trendy thing in the recent years. I won't recommend the actual project I explained back then in the [3], but the overall idea still valid, and there are several big and small offerings for that nowadays. Hope this will help. [1]: https://rakyll.org/coredumps/ [2]: https://pkg.go.dev/runtime/debug#SetTraceback [3]: https://medium.com/@tvii/continuous-profiling-and-go-6c0ab4d2504b On Tuesday, January 10, 2023 at 8:55:18 AM UTC+1 mariappa...@gmail.com wrote: > Hello Go experts, > > I could able to find the solution to debug memory leaks of GO process, > when it is running by using PPROF. Is it possible to collect the heap > profile for debugging, when GO process crashed using core dump? or what is > the recommended way to root cause the memory leak? Based on the need, > enabling PPROF and debugging may not be possible in the production > environment. Please help. > > Best Regards > Mariappan > -- 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/b33dc147-7099-494c-8a04-e4507d410d8dn%40googlegroups.com.
