Ian, Any thoughts on this? Appreciate a response. Thanks Naveen
On Tue, 5 May, 2020, 8:34 PM Naveen Kak, <naveen.ka...@gmail.com> wrote: > 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/CAHB4VaCt5c1BC3BhtcA%2BZ%2BoudFrkY8XY%2BGvGh7n%2BHmcgJOjEUw%40mail.gmail.com.
