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 (
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
>
> 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
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
Yes. please do. We should also update our JVM defaults.
On Thu, Jan 23, 2020, 9:28 PM Jeremy Hanna
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
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
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
I think what he means is that if users have existing clusters with
num_tokens=256 (current default) and the default changes to 32, the node
won't ignore the value, it will fail to start with an error that you cannot
change from one num_tokens value to another:
ERROR [main] 2020-01-22 17:10:53,159
On Tue, Jan 21, 2020 at 7:41 PM Jonathan Koppenhofer
wrote:
> If someone isn't explicitly setting vnodes, and the default changes, it
> will vary from the number of assigned tokens for existing clusters, right?
> Won't this cause the node to fail to start?
>
Nope. You can have 32 tokens on some
If someone isn't explicitly setting vnodes, and the default changes, it
will vary from the number of assigned tokens for existing clusters, right?
Won't this cause the node to fail to start?
I am in favor of changing these defaults, but should provide very clear
guidance on vnodes (unless I am
10 matches
Mail list logo
