Benedict commented on CASSANDRA-12668:
(breaking out of nesting hell)
I don't really have the inclination for a philosophical debate about what
should or should not be prioritised. However the number of clusters we've had
in the past falling over due to runaway compaction is a more prevalent use case
that this change was designed to help fix. Which one is more important, I
cannot say with certainty, but it's never as black and white as "never make
anything worse for anyone" - e.g. thrift users are getting, well, short thrift
(hehe) at present.
bq. These are not statements
Anyway. The important qualifier is that they were qualitative/correlative,
i.e. lacking any numbers for comparison or direct mechanisms/causes for the
action, nor any information by which we could make any guesses as to such.
i.e., it's much too speculative to be reaching the conclusions you have about
cause, or having this detailed a discussion at present, really.
There are two ways to attack this: inwards or outwards. Either try to provide
all of the contextual information to find avenues to explore via cluster
testing, or isolate the b-tree and snaptree to see how they compare under
varying levels of contention (with semantics as in the databases, i.e.
> Memtable Contention in 2.1
> Key: CASSANDRA-12668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12668
> Project: Cassandra
> Issue Type: Bug
> Reporter: sankalp kohli
> We added a new Btree implementation in 2.1 which causes write performance to
> go down in Cassandra if there is lot of contention in the memtable for a CQL
> partition. Upgrading a cluster from 2.0 to 2.1 with contention causes the
> cluster to fall apart due to GC. We tried making the defaults added in
> CASSANDRA-7546 configurable but that did not help. Is there anyway to fix
> this issue?
This message was sent by Atlassian JIRA