Of course now that I sent this email, I have just noticed this pprof flag: -base <profile> Show delta from this profile
I haven't tried it yet, but this seems like it might solve these problems. -Caleb On Thu, Sep 29, 2016 at 2:12 PM, Caleb Spare <cesp...@gmail.com> wrote: > pprof gives two kinds of heap profiles: (please let me know if any of > this is not correct) > > - inuse_space -- a profile of the currently live objects/bytes on the heap > - alloc_space -- a profile of the allocated objects/bytes since program > startup > > When I need to figure out why my heap is so big, inuse_space is > usually very helpful. However, I've found that alloc_space is > sometimes less helpful for the other kind of memory analysis I > typically need to perform. > > Here are two scenarios I've hit in which alloc_space doesn't quite cut it: > > - A server operates by allocating a bunch of large data structures on > startup and then starts handling requests. I'd like to optimize the > request handling and reduce some allocations but alloc_space is > initially dominated by the initialization. > - A server has been running normally for days and then suddenly starts > allocating somewhat more than usual. I look at an alloc_space profile, > but it's dominated by the allocations from normal operation. > > What I'd really like is some better way to profile recent allocations. > It seems like two options could be (a) another heap profile mode that > shows allocations since the last GC or (b) a way to ask the runtime to > reset allocation counts. > > Am I making sense? Did I misunderstand how all this works or miss some > profiling feature? > > Thanks! > Caleb -- 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.
