I just wanted to close the loop for https://issues.apache.org/jira/browse/CASSANDRA-14902 (update compaction_throughput_mb_per_sec default from 16 to 64) - the default will become 64 for 4.0 unless people had strong objections. I'll update the separate discussion on num_tokens ( https://issues.apache.org/jira/browse/CASSANDRA-13701) but that is getting finalized after some testing.
On Sat, Jan 25, 2020 at 2:59 AM Alexander Dejanovski <a...@thelastpickle.com> wrote: > I support changing the default GC settings. The ones we have now drive me > nuts. > We should raise the max heap size for CMS to 16G instead of 8 now. We > should still not go higher than half the available RAM. > Also, we should set a new gen size between 40% and 50% of the heap size. > The 100MB per core rule for computing the new gen size doesn't make any > sense IMO (at least in the context of Cassandra). > > This is one of the most common optimizations we make on clusters, and most > peeps that run Cassandra aren't GC experts (and shouldn't be). > > ----------------- > Alexander Dejanovski > France > @alexanderdeja > > Consultant > Apache Cassandra Consulting > http://www.thelastpickle.com > > > On Fri, Jan 24, 2020 at 3:48 PM Joshua McKenzie <jmcken...@apache.org> > wrote: > > > > > > > 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? > > > > > > Just realized I can no longer create epics anymore (or the "new" JIRA UI > is > > just so obtuse I can't figure it out. I give it 50/50 odds). Thinking > this > > may have been due to transition to LDAP. > > > > Since I planned on experimenting with the whole "what does the confluent > > testing page look like in an epic" today, I'll ping Nate once it's not > > godawfully early in NZ about this. Or he'll read this email, either way. > :) > > > > On Thu, Jan 23, 2020 at 11:13 PM Jeremy Hanna < > jeremy.hanna1...@gmail.com> > > wrote: > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > >
