Hi, Christian, Whereas pprof seems to be the way to go, have you tried to plot a chart of memory usage over time? Depending where you're running it, it might me easy to get this info. Once I had to chase a small "CPU leak ", slowly over a long time (days-weeks) the program CPU consumption would only increase and after a restart it'd start always with a very low CPU consumption. Then after confirming it, a lot of time spent with pprof. My 2 cent here, is fist make sure there is a leak, only then try to find where it is. Also after a longer time, if some part of you code is holding a lot of memory, as more memory it hold, easier it should be to pin pint with pprof.
Good luck, Anderson On Monday, 5 July 2021 at 13:18:49 UTC+2 Christian Worm Mortensen wrote: > I want to hear if anybody has an idea on how I can find a very small > memory leak in a Go program? The program is a service running for days and > weeks. I am not even 100% sure there is a memory leak, but when I look at > the memory usage graphs based on data from runtime.ReadMemStats it looks > like that possibly there is. As far as I can tell this would be the optimal > way to find the leak: > > > - Let the program run for 1 day > - Make a memory dump A using debug.WriteHeapDump > - Let the program run for 1 additional day. > - Make a memory dump B using debug.WriteHeapDump > - Let the program run for 1 additional day. > - Make a memory dump C using debug.WriteHeapDump > > From these dumps, create a list of all objects which are in present in B > and C but not in A. These would be long-living objects which are allocated > long after the program started. And this will kind of be the definition of > a leak in my program. > > Now, it seems like there are not really any tools supporting > debug.WriteHeapDump so I don’t think this is possible without creating such > a tool myself? > > The canonical way to find memory leaks seems to be the performance > profiler https://github.com/google/pprof/blob/master/doc/README.md. But > as far as I can see, it is not really useful to find small memory leaks > like the one I describe? Maybe if I run my program for a very long time the > leak would contribute to a non-trivial amount of memory currently > allocated. Still, the amount of memory *allocations* that contribute to the > leak would be very small. Would there be a way to use the performance > profiler in this case? Any hints would be appreciated, thanks! > -- 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/faec9227-98f6-4128-9ed1-c92dafdcd4b9n%40googlegroups.com.
