Closed let4be closed 6 years ago
@let4be can you provide more information on this? I'm tracking down a memory leak where I would have thought calling registry.UnregisterAll()
freed the resources, but that doesn't appear to be the case.
Interesting. I can say with SOME confidence that "ephemeral meters" is likely a thing that wasn't considered/designed for.
I'm using go-metrics
as I consume and parse events from Kafka. Every "event" contains a name
and a scope
. I then call metrics.GetOrRegisterMeter("counter-<scope>-<name>, registry).Mark(1)
each time I consume an event. Every second I iterate over metrics, looking for meters, then punt the counters somewhere downstream and then call registrry.UnregisterAll()
.
This is leaking for me:
Fetching profile from http://localhost:8888/debug/pprof/heap
Saved profile in /Users/davidariens/pprof/pprof.localhost:8888.inuse_objects.inuse_space.086.pb.gz
Entering interactive mode (type "help" for commands)
(pprof) top10
13326.09kB of 13326.09kB total ( 100%)
Dropped 67 nodes (cum <= 66.63kB)
Showing top 10 nodes out of 29 (cum >= 1541.07kB)
flat flat% sum% cum cum%
10760.92kB 80.75% 80.75% 10760.92kB 80.75% reflect.Value.cal
That reflect.Value.cal
grows until out-of-memory.
Is there any work-around here or should I drop go-metrics
and adopt some locking string/int map based counter on my own?
it was a while ago I was looking for this, don't have all details right now Afaik it's not possible to stop meter ar all, i.e. free all associated with it resources
I checked the code and it seems it's totally impossible to stop a meter i.e. using lots of disposable meters gonna end up in a massive resource waste