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')? -- 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.
