> > how much memory the Timers can currently use
Timer is currently backed by a DecayingEstimatedHistogramReservoir. [1] Each DecayingEstimatedHistogramReservoir defaults to allocate [2] 1. *bucketOffsets*: a long array with the length of 164 2. *decayingBuckets*: a long array with the length of 165 * 2 3. *buckets*: a long array with the length of 165 * 2 Each timer instance consumes 6592 bytes roughly. (Only counting the long arrays, which are the main contributors) There are a bunch of timers, per verb, per keyspace, per table, etc. Although adding them up might still not be a concern. As mentioned, recording in the micros can halve the memory usage. Not a significant saving compared with other components, but still good to have if nanos is not necessary. The major benefit is making the duration unit consistent. [1] https://github.com/apache/cassandra/blob/aac6f7db8c8f493b8e28842903e6e2cb6838ac75/src/java/org/apache/cassandra/metrics/CassandraMetricsRegistry.java#L101 [2] https://github.com/apache/cassandra/blob/aac6f7db8c8f493b8e28842903e6e2cb6838ac75/src/java/org/apache/cassandra/metrics/DecayingEstimatedHistogramReservoir.java#L79 On Fri, Jun 25, 2021 at 7:26 AM Joshua McKenzie <jmcken...@apache.org> wrote: > +1 to unifying on the same unit for API consistency; micros should be quite > fine for most if not all of our use-cases. > > > On Fri, Jun 25, 2021 at 8:58 AM Brandon Williams <dri...@gmail.com> wrote: > > > On Fri, Jun 25, 2021 at 6:17 AM Mick Semb Wever <m...@apache.org> wrote: > > > > > > I'm for (1) if this is for 4.1 only. Changes like this over our annual > > releases should be fine if they are clearly documented, it's what > NEWS.txt > > is for. > > > > +1, we have the process in place to handle this. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
