Re: [go-nuts] Change in virtual memory patterns in Go 1.12

I'm glad to hear it! What went into Go 1.12.5 should supersede that patch anyway. On Wed, May 8, 2019 at 3:48 AM Rémy Oudompheng wrote: > Hello, > > I didn't have time to try the patch, but as Go 1.12.5 is out with another > fix, I can confirm with high certainty that the problem is now gone, an

Re: [go-nuts] Change in virtual memory patterns in Go 1.12

Hello, I didn't have time to try the patch, but as Go 1.12.5 is out with another fix, I can confirm with high certainty that the problem is now gone, and I am pretty much confident that the situation is even better than Go 1.11, which is consistent with the fact that the bug was already there, but

Re: [go-nuts] Change in virtual memory patterns in Go 1.12

Hi Michael, I found my way to this thread as we are experiencing similar issues in one of our applications after upgrading from 1.11.1 to 1.12.4. Our application has a lot of persistent, large, busy maps so we periodically recreate them per https://github.com/golang/go/issues/20135. What we a

Re: [go-nuts] Change in virtual memory patterns in Go 1.12

Hey Rémy, If you have a chance, could you please try out this patch ? It's been known to help the other application Austin mentioned with virtual memory footprint and it should patch cleanly onto the go1.12. Let me know what you see! It'd help u

Re: [go-nuts] Change in virtual memory patterns in Go 1.12

On Tue, Apr 16, 2019 at 1:23 AM Rémy Oudompheng wrote: > Thanks Austin, > > The application workload is a kind of fragmentation torture test as it > involves a mixture of many long-lived small and large (>100 MB) > objects, with regularly allocated short-lived small and large objects. > I have tr

Re: [go-nuts] Change in virtual memory patterns in Go 1.12

Thanks Austin, The application workload is a kind of fragmentation torture test as it involves a mixture of many long-lived small and large (>100 MB) objects, with regularly allocated short-lived small and large objects. I have tried creating a sample synthetic reproducer but did not succeed at th

Re: [go-nuts] Change in virtual memory patterns in Go 1.12

Hi Rémy. We often fight with vm.max_map_count in the runtime, sadly. Most likely this comes from the way the runtime interacts with Linux's transparent huge page support. When we scavenge (release to the OS) only part of a huge page, we tell the OS not to turn that huge page frame back into a huge

[go-nuts] Change in virtual memory patterns in Go 1.12

Hello, In a large heap program I am working on, I noticed a peculiar change in the way virtual memory is reserved by the runtime : with comparable heap size (about 150GB) and virtual memory size (growing to 400-500GB probably due to a kind of fragmentation), the number of distinct memory mappings