Hi Ian, I explored a few things, calling debug.FreeOSMemory periodically. This does help, I see a definitely a change in the memory being returned to the OS ( looking at top o/p). I also set the "GODEBUG=madvdonotneed=1", as per go documentation post 1.12 release, go release it uses "madvfree" option which is basically a lazy free to the OS. This didn't surprisingly did not have any effect. So one thing for sure that deleting map definitely doesn't have any bug, its the way GC is working, not releasing everything back to OS ( I think after running for 12 hours or so, if we leave the system idle i don't think memory gets released back to OS, GC probably thinks it will be required to ask for memory so holds on to it unless we call the debug.FreeOSMemory periodically).
What you think about using "sync pools" so that there are no frequent memory allocations/de-allocations?, haven't explored this much yet. Another thing, calling debug.FreeOSMemory periodically does cause CPU spikes. Regards Naveen On Wed, Apr 29, 2020 at 2:16 AM Ian Lance Taylor <i...@golang.org> wrote: > On Tue, Apr 28, 2020 at 1:00 PM Naveen Kak <naveen.ka...@gmail.com> wrote: > >> Basically using the Top command at end of test. >> > > The top command will show you the memory that the program has requested > from the operating system and has not returned to the operating system. > The Go memory allocator works by requesting memory from the operating > system as it needs it. The Go garbage collector works by looking at that > memory and marking it as available for future allocations by the Go memory > allocator. The Go garbage collector does not immediately return memory to > the operating system. That is because requesting from and returning to the > operating system are relatively slow operations, and a program that has > needed memory once is likely to need it again. > > So the top program is not a good way to judge what the garbage collector > is doing. It is an OK way to judge the maximum memory use of the program, > which will include memory that has been allocated and memory that has been > garbage collected. > > If a Go program runs for a while with excess memory, it will slowly return > it to the operating system. You can encourage that process by using > runtime/debug.FreeOSMemory. > > In general, though, if you want to examine the garbage collector, I > recommend that you use runtime.ReadMemStats rather than top. > > Ian > -- 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/CAHB4VaC5Kt_XdM8fA3tbzS01xPeFAymZHtp0USo6ftQkD0U%3DOg%40mail.gmail.com.
