I've previously created https://issues.apache.org/jira/browse/CASSANDRA-14902 for updating the compaction_throughput_in_mb default. I created https://issues.apache.org/jira/browse/CASSANDRA-15521 for updating the num_tokens default, https://issues.apache.org/jira/browse/CASSANDRA-15522 for updating the [roles|permissions|credentials]_validity_in_ms defaults, and https://issues.apache.org/jira/browse/CASSANDRA-15523 for updating the default snitch to GossipingPropertyFileSnitch. I'm unable to create an epic in the project - not sure if that has to do with project permissions. Could someone create an epic and link these tickets as subtasks? Jon - would you mind creating the ticket around JVM defaults? Are you thinking of the default GC and settings for a better out of the box experience? Thanks all, Jeremy
On Fri, Jan 24, 2020 at 1:57 PM Jon Haddad <j...@jonhaddad.com> wrote: > Yes. please do. We should also update our JVM defaults. > > On Thu, Jan 23, 2020, 9:28 PM Jeremy Hanna <jeremy.hanna1...@gmail.com> > wrote: > > > To summarize this thread, I think people are generally okay with updating > > certain defaults for 4.0 provided we make sure it doesn't unpleasantly > > surprise cluster operators. I think with the num_tokens and > > compaction_throughput_in_mb we could go with a release note for the > reasons > > in my last email. I also agree that we should consider bump > > roles_validity_in_ms, permissions_validity_in_ms, and > > credentials_validity_in_ms along with the default snitch (going to > GPFS > > as the default) as that gives people a DC aware default at least to > start. > > > > Is everyone okay if I create tickets for each of these and link them with > > an epic so that we can discuss them separately? > > > > Thanks, > > > > Jeremy > > > > On Thu, Jan 23, 2020 at 5:34 AM Alex Ott <alex...@gmail.com> wrote: > > > > > In addition to these, maybe we could consider to change other as well? > > > Like: > > > > > > 1. bump roles_validity_in_ms, permissions_validity_in_ms, and > > > credentials_validity_in_ms as well - maybe at least to a minute, or > > 2. I > > > have seen multiple times when authentication was failing under the > > heavy > > > load because queries to system tables were timing out - with these > > > defaults people may still have the possibility to get updates to > > > roles/credentials faster when specifying _update_interval_ variants > of > > > these configurations. > > > 2. change default snitch from SimpleSnitch to > > GossipingPropertyFileSnitch - > > > we're anyway saying that SimpleSnitch is only appropriate for > > > single-datacenter deployments, and for real production we need to > use > > > GossipingPropertyFileSnitch - why not to set it as default? > > > > > > > > > Jeremy Hanna at "Wed, 22 Jan 2020 11:22:36 +1100" wrote: > > > JH> I mentioned this in the contributor meeting as a topic to bring up > > on > > > the list - should we > > > JH> take the opportunity to update defaults for Cassandra 4.0? > > > > > > JH> The rationale is two-fold: > > > JH> 1) There are best practices and tribal knowledge around certain > > > properties where people > > > JH> just know to update those properties immediately as a starting > > > point. If it's pretty much > > > JH> a given that we set something as a starting point different than > the > > > current defaults, why > > > JH> not make that the new default? > > > JH> 2) We should align the defaults with what we test with. There may > > be > > > exceptions if we > > > JH> have one-off tests but on the whole, we should be testing with > > > defaults. > > > > > > JH> As a starting point, compaction throughput and number of vnodes > seem > > > like good candidates > > > JH> but it would be great to get feedback for any others. > > > > > > JH> For compaction throughput ( > > > https://jira.apache.org/jira/browse/CASSANDRA-14902), I've made > > > JH> a basic case on the ticket to default to 64 just as a starting > point > > > because the decision > > > JH> for 16 was made when spinning disk was most common. Hence most > > > people I know change that > > > JH> and I think without too much bikeshedding, 64 is a reasonable > > > starting point. A case > > > JH> could be made that empirically the compaction throughput throttle > > may > > > have less effect > > > JH> than many people think, but I still think an updated default would > > > make sense. > > > > > > JH> For number of vnodes, Michael Shuler made the point in the > > discussion > > > that we already test > > > JH> with 32, which is a far better number than the 256 default. I > know > > > many new users that > > > JH> just leave the 256 default and then discover later that it's > better > > > to go lower. I think > > > JH> 32 is a good balance. One could go lower with the new algorithm > but > > > I think 32 is much > > > JH> better than 256 without being too skewed, and it's what we > currently > > > test. > > > > > > JH> Jeff brought up a good point that we want to be careful with > > defaults > > > since changing them > > > JH> could come as an unpleasant surprise to people who don't > explicitly > > > set them. As a > > > JH> general rule, we should always update release notes to clearly > state > > > that a default has > > > JH> changed. For these two defaults in particular, I think it's safe. > > > For compaction > > > JH> throughput I think a release not is sufficient in case they want > to > > > modify it. For number > > > JH> of vnodes, it won't affect existing deployments with data - it > would > > > be for new clusters, > > > JH> which would honestly benefit from this anyway. > > > > > > JH> The other point is whether it's too late to go into 4.0. For > these > > > two changes, I think > > > JH> significant testing can still be done with these new defaults > before > > > release and I think > > > JH> testing more explicitly with 32 vnodes in particular will give > > people > > > more confidence in > > > JH> the lower number with a wider array of testing (where we don't > > > already use 32 explicitly). > > > > > > JH> In summary, are people okay with considering updating these > defaults > > > and possibly others > > > JH> in the alpha stage of a new major release? Are there other > > > properties to consider? > > > > > > JH> Jeremy > > > JH> > > --------------------------------------------------------------------- > > > JH> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > JH> For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > > > -- > > > With best wishes, Alex Ott > > > Principal Architect, DataStax > > > http://datastax.com/ > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > >
