On Thu, Dec 20, 2018 at 2:13 PM <nuss.jus...@gmail.com> wrote: > > 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).
Thanks--do you want to suggest some better wording? Ian > 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. -- 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.
