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. 
cas-swapped head).

> 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

Reply via email to