Re: [go-nuts] Re: Lots of retained free spans

Go GC does not use a compacting/copying collector so depending on your allocation patterns you could see this behavior. But you’re stating > 70% free spade available. I.e It may be that these are holes that cannot be released to the OS. > On May 29, 2023, at 10:08 AM, Gleb Petrovichev > wro

[go-nuts] Re: Lots of retained free spans

I'm having the exactly same problem now. Did you by any chance able to figure it out? I'm compiling with go1.19.8 though. Thanks On Saturday, January 29, 2022 at 2:02:18 AM UTC+1 Eric Hubbard wrote: > I've been trying to root cause an OOM condition. My process is running > within a cgroup with

[go-nuts] Re: Lots of retained free spans

Go doesn't know about memory pressure, but rather it informs the OS about pages it no longer needs, and the OS deals with memory pressure. See the madvise(2) manpage and the go1.12 release notes . If I und

[go-nuts] Re: Lots of retained free spans

How does go know about memory pressure? maybe that aspect is broken in my environment... within a cgroup..etc.. On Saturday, 29 January 2022 at 02:16:56 UTC-8 Brian Candler wrote: > What go version are you compiling with? > > go prior to 1.16 would hold onto memory such that the OS would only

[go-nuts] Re: Lots of retained free spans

v1.16.4 On Saturday, 29 January 2022 at 02:16:56 UTC-8 Brian Candler wrote: > What go version are you compiling with? > > go prior to 1.16 would hold onto memory such that the OS would only > reclaim it when under memory pressure; it could be made to free memory > eagerly using GODEBUG=madvdon

[go-nuts] Re: Lots of retained free spans

What go version are you compiling with? go prior to 1.16 would hold onto memory such that the OS would only reclaim it when under memory pressure; it could be made to free memory eagerly using GODEBUG=madvdontneed=1. This was made the default in go 1.16. https://discuss.dgraph.io/t/benchmarks-