Re: [DISCUSS] CASSANDRA-16760 - JMXTimer exposes attributes in inconsistent time units
> There are several options (all for timers specifically): > >1. Enforce the consistency of the time unit. > - Change all JMXTimers to store values in micros and reduce the > bucket size to 90. The change has no impact on reading the > statistics. But > the long[] of Values and RecentValues is reduced to 91, and the > values are > based on micros. > - Change all JMXTimer to store values in nanos. The change makes the > percentiles, mean values returned in nanos. But has no impact on the > histogram raw values, i.e., Values and RecentValues. >2. Having a toggle to either keep the current inconsistency or records >all in micros. This is less invasive than option 1. And it does not affect >your monitoring tooling if it reads the Values (histogram raw values) at >nanos resolution. > > I'd prefer option 1. So the DurationUnit attribute correctly annotates the > other attributes from the JMXTimer. For most of the timers, we do not need > the nanos resolution. Recording them in micros halves the memory footprint > for timers. If some timers do need the nanos resolution, the duration unit > can be changed to nanos. The external process that reads the attributes can > correctly interpret the values based on the duration unit. > > Thoughts? 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. I'm curious to know any rough idea of how much memory the Timers can currently use, and which timers we think still need the nano resolution. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] CASSANDRA-16760 - JMXTimer exposes attributes in inconsistent time units
On Fri, Jun 25, 2021 at 6:17 AM Mick Semb Wever 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
Re: Additions to Cassandra ecosystem page?
I'm a huge +1 to the sentiments here. I have to confess that I've been responsible for publishing the updates for several months now with Mick's mentoring. I publish the content I was requested to push to the site but as far as review is concerned, the only review I do is mostly around grammar and formatting and make sure that the updates render correctly on the site. It would be ideal if there was a charter from the community I could refer to so it wouldn't seem like I'm unilaterally rejecting some entries but not others. I'm glad we've got this thread because I could use it to support what I do on the site. Cheers!
Re: [DISCUSS] CASSANDRA-16760 - JMXTimer exposes attributes in inconsistent time units
+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 wrote: > On Fri, Jun 25, 2021 at 6:17 AM Mick Semb Wever 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 > >
Re: Additions to Cassandra ecosystem page?
> > I'm also comfortable with a strict approach where we just list actual > Apache Cassandra offerings, that also provides good solid clarity to > users. That sounds like a reasonable proposal. I just do not know how we can do that in practice. What is a actual Apache Cassandra offering and how do we check that it is effectively one ? What if the offering offers some secondary indices that are not delivered with Apache Cassandra (it is the first pluggable thing that came to my mind) or the code being used is a C* fork? Two things that I found interesting are: 1 ) some companies that propose offerings only using some parts of Apache Cassandra are contributing to the project in diverse ways 2) the offer descriptions seem honest to me. They do not claim that they run the official Apache Cassandra if they do not. So, I would be more in favor of a welcoming approach in the hope that people will be honest and that it might also lead them to invest and contribute to the project. The other advantage of that approach being that it will not put any pressure on us to ensure that an offering is an actual Apache Cassandra offering (which I am absolutely not interested in doing ;-)) Le ven. 25 juin 2021 à 15:28, Erick Ramirez a écrit : > I'm a huge +1 to the sentiments here. > > I have to confess that I've been responsible for publishing the updates for > several months now with Mick's mentoring. I publish the content I was > requested to push to the site but as far as review is concerned, the only > review I do is mostly around grammar and formatting and make sure that the > updates render correctly on the site. > > It would be ideal if there was a charter from the community I could refer > to so it wouldn't seem like I'm unilaterally rejecting some entries but not > others. I'm glad we've got this thread because I could use it to support > what I do on the site. Cheers! >
Re: [DISCUSS] CASSANDRA-16760 - JMXTimer exposes attributes in inconsistent time units
> > 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 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 wrote: > > > On Fri, Jun 25, 2021 at 6:17 AM Mick Semb Wever 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 > > > > >
