The wording is kinda bad. All it means is that the runtime was updated to use MADV_FREE instead of MADV_DONTNEED if possible.
You can read about the difference on the madvise(2) man page, but basically MADV_FREE is more lazy. There is no actual impact other than the RSS value being not as accurate / up to date. The relevant change is https://golang.org/cl/135395 (btw. you can find the CL numbers as comments in the HTML of the release notes). On Thursday, December 20, 2018 at 9:37:54 PM UTC+1, Aaron Beitch wrote: > > I'm trying out a build of my code under go1.12beta1 and resident memory > usage is not too dramatically different than under go1.11. The wording on > this release note made me think the runtime was going to continually gobble > up memory and not release any until the system had nearly run out, but that > doesn't appear to be the case. I would still be interested to learn more > about the details on the new behavior. > > The process in question typically uses more memory at start as it has to > sync a bunch of data with a backend, and then after a few minutes it > reaches a steady-state where it is only sending updates. Prior to go1.12 I > would see the memory usage grow to its maximum shortly after start and then > drop ~10% a few minutes after reaching steady-state. In go1.12 it spends a > bit more time at the elevated memory usage, but appears to gradually reduce > memory over time. > > Thanks, > Aaron > > On Thursday, December 20, 2018 at 11:16:47 AM UTC-8, Aaron Beitch wrote: >> >> Hello, >> >> This caught my eye from the go1.12beta1 release notes: >> >> On Linux, the Go runtime now releases memory back to the operating system >>> only when the OS is under memory pressure. This is more efficient, but >>> means a process's RSS (resident set size) won't decrease unless the OS is >>> running out of memory. >> >> >> I work on Go programs that are deployed on sometimes memory-constrained >> Linux systems that run many other non-Go processes. At least the optics of >> a process consuming nearly all system memory is concerning to me. In >> addition, I'm concerned about how quickly the go runtime will react to a >> sudden increase in memory pressure. >> >> Can I get a pointer to any documentation or code that discusses what >> triggers the runtime to release memory and how quickly it will react? Can >> this behavior be controlled by any flags? >> >> One solution we could implement is to periodically run >> debug.FreeOSMemory, but that doesn't sound so nice. >> >> Thanks, >> Aaron >> > -- 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. For more options, visit https://groups.google.com/d/optout.
