Looks like we all agree on option 1. I have submitted a patch to the trunk branch. It unifies the duration unit and defaults to micros. As a result, all timers will start to record time values in micros instead of nanos.
Please let me know if there is any concern with the change. - Yifan On Fri, Jun 25, 2021 at 1:57 PM Yifan Cai <yc25c...@gmail.com> wrote: > 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 >> > >> > >> >
