tank chunk keeping vs clearing, GC, refactoring about metrictank HOT 2 CLOSED

The primary purpose of the GC tasks is to handle metrics that are no longer being produced.

there is no need to clear the old data, because it wouldn't gain us any memory back.

This doesn't make any sense. How can deleting unused data not free memory? The memory might not get released back to the kernel, but it does get released back to the GO vm. When a metric stops receiving new data, the GC task will first persist the unfinished chunk (by the default the GC runs every hour, so if no metric has been received for an hour the chunk is persisted). If the last saved chunk is more then GC time + (chunkspan * numchunks), then the entire aggmetric is purged from memory. So if the app is tuned to keep 3 hours of data in memory and the default GC of 1 hour is used, then the aggmetric won't be purged until it hasn't been written to for 5hours.

it's IMHO better to just avoid GC and let data expire naturally.

Stale metrics need to be purged from memory to make way for new metrics. Once the aggmetric is created (with the circular buffer) it will live forever unless we delete it. Keeping stale metrics in memory indefinitely just doesnt make any sense.

re #42

• it might be more lines of code but it is significantly simpler code. Additionally the old code used the app start_time to calculate things which could be used any more after the save/load at stop/start time was added.
• It may impact this, but the worst case scenario is that a few metrics will be rejected due to the last chunk being forcefully finished and persisted to disk. And even then this can be addressed pretty easily.
• Yes there is definitely room for optimizations. But if we try to make everything perfect before pushing this to production we will be waiting forever.

from metrictank.

after discussion with AJ, i actually like the new cbuf format. it basically doesn't map chunks to given positions by modulo'ing the t0's. rather it just appends at the end and starts over when needed. this gracefully handles gaps. and indeed, the new code is more elegant and simple.
and keeping older data as long as we don't need to clear/reuse their slots also simply follows out of this design, with a configurable setting for when "too old really is too old" 👍

from metrictank.