On Tue, Nov 29, 2016 at 6:57 PM, Levi Corcoran <allg...@gmail.com> wrote:
>
> While investigating climbing memory usage for one of our services, I've
> noticed a continual increase in the BuckHashSys metric from runtime.MemStats
> ("bytes of memory in profiling bucket hash tables"), from 0 to ~2.5GB in the
> span of about 20 days, and no signs of stopping. This is an application
> with a fairly steady ~8GB HeapInUse.
>
> I've checked and we're using the default MemProfileRate granularity. We do
> regularly call runtime.ReadMemStats() (every 30 seconds) for logging
> purposes, and we do have the pprof endpoints wired up for debugging as
> needed, although we shouldn't have anything regularly capturing profile data
> AFAIK.
>
> This is currently on Go 1.5.3 for various reasons, although I believe
> they're upgrading to 1.7x with their next deployment and I'm eager to see
> how things behave there.
>
> What factors could be contributing to that continual climb of BuckHashSys
> and how can we control/mitigate that?
Each time the heap profile captures a new stack--a stack that hasn't
been seen before--the stack is saved in memory accounted for in
BuckHashSys. While I could easily be missing something, I don't see
anything else that could cause BuckHashSys to grow over time. So this
could happen if you are doing heap profiling in an application that
allocates memory in lots and lots of different places. It might be
worth looking at a heap profile to see how spread out memory
allocation is.
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.
