Thanks for the clarification. The system I am testing on is swapless, so maybe would explain why RSS is not increasing.
> On a swapless system, freeing pages in a given range happens instantly, > regardless of memory pressure. > My suggestion for wording would to be more specific about the details: "On Linux systems MADV_FREE is now used by the runtime to release unused memory spans. This may result in higher reported RSS. The kernel will reclaim the unused data when it is needed." On Thursday, December 20, 2018 at 2:20:22 PM UTC-8, Ian Lance Taylor wrote: > > On Thu, Dec 20, 2018 at 2:13 PM <[email protected] <javascript:>> 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 [email protected] <javascript:>. > > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
