On Tue, Nov 29, 2016 at 10:27 PM, Levi Corcoran <allg...@gmail.com> wrote: > Thanks much. Memory allocation does indeed appear 'spread out' as a result > of some recursive function calls of varying depth that get called during > serialization, and a variety of code paths that can trigger the > serialization, at least after a quick skim through portions of very large > /debug/pprof/heap?debug=1 output. From longer-running instances, the > profiles actually get too large to retrieve in entirety (many-GB memory > spikes when they are accessed hit container memory limits). > > Can you clarify what makes it a new/unique stack worthy of tracking? And > should these profile stacks get GC'd once the memory allocation that > triggered them gets GC'd, or are they retained forever (should their > overhead scale with 'Alloc' or 'TotalAlloc')?
A stack trace is up to 32 function calls. A stack trace is new if it is different from any stack trace previously seen. Stack traces do not get GC'ed; they are retained forever. The expectation of this code is that most programs allocate memory in predictable places, so the number of stack traces does not normally get too large. It may be that this assumption is false for your program. As you know, whether a stack trace is collected for a particular memory allocation is controlled by runtime.MemProfileRate. You could simply set that variable to 0, though of course you would then not be able to collect a memory profile. Ian -- 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.
