Just to note, from a Perl background (learning Go atm so this may not apply, just trying to indicate it may be "normal"), I think this isn't necessarily unusual for a process to not free up memory, and it's an OS limitation (again I may be barking up the wrong tree). Elsewhere (i.e not Go), I've got around this problem by running a new process that eats up the memory, processes, and then dies, returning the response to the original process (so memory isn't allocated for a long term, we have processes that sometimes run for best part of a whole day).
Ian On Sun, Apr 18, 2021 at 7:18 PM Trig <edb1...@gmail.com> wrote: > From further research (and anybody correct me if this is wrong), when the > GC does collect memory the profile shrinks, but *no memory is returned to > the system*. Any future allocations will try to use memory from the pool > of previously collected objects before asking the system for more. This is > why things are behaving this way. > > On Sunday, April 18, 2021 at 12:34:44 PM UTC-5 Trig wrote: > >> Also, I don't think it's the Stack. If you replace Alloc with >> HeapAlloc... it's all there. >> >> On Sunday, April 18, 2021 at 12:33:20 PM UTC-5 Trig wrote: >> >>> Correct... the example using time.Sleep didn't run on the playground. >>> The original post I made, I provided the link with just a goroutine with an >>> empty function. >>> >>> At least you were able to reproduce what I'm inquiring about. I'll look >>> further into this, but surely unused and finished goroutines don't leave >>> stuff laying around like that. >>> >>> On Sunday, April 18, 2021 at 3:47:10 AM UTC-5 Brian Candler wrote: >>> >>>> What do you mean by "It won't work on the playground"? It runs for >>>> me. Are you saying you get different results when running locally? If so, >>>> what version of go are you running locally, on what platform, and what do >>>> you see? >>>> >>>> Or are you saying the problem is really with something like this? >>>> https://play.golang.org/p/Q91Qd-DvvKx >>>> >>>> That indeed fails to run in the playground - it exits with signal 9 >>>> (128+9=137) >>>> >>>> Running locally with go 1.16.3 under macOS (Intel) I see: >>>> >>>> Allocs before: 82696 >>>> Allocs while running: 51496728 >>>> Allocs after: 40384112 >>>> Allocs after: 40384112 >>>> Allocs after: 40384112 >>>> Allocs after: 40384112 >>>> Allocs after: 40384112 >>>> >>>> That is 40MB that apparently isn't reclaimed, but it does get reused if >>>> you run more goroutines: >>>> https://play.golang.org/p/YcMTlLYxXAP >>>> >>>> I don't know why that is. It's about 400 bytes per goroutine. Stack >>>> perhaps? >>>> >>> -- > 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/f42e270a-7ae9-4f11-bb85-d94bcbd331f1n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/f42e270a-7ae9-4f11-bb85-d94bcbd331f1n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CANAUX_S%2B93ReurP8J5h_kFxPvRNHTsSscpNFdU55A7Ap3mKvRA%40mail.gmail.com.
