Benedict commented on CASSANDRA-12668:

There's a big difference between a test and a real life cluster though - are 
all your assertions wrt the testing only?  The amount of contention, size and 
number of your partitions as well as the number of non-contending operations 
are all hugely important to the emergent behaviour here.  

You also seem to be switching between discussing throughput and GC burden. The 
lower throughput may be because the 7546 synchronous behaviour kicks in - which 
it does once it detects ~10MB/s of waste, which depending on your test could 
easily be triggered.

Of course, it may well also be that for your test case it is inherently worse; 
not every use case can be improved.

While the SnapTreeMap pointer was always updated via CoW, the tree itself was 
only modified internally, so fewer nodes would be discarded on a failed 
modification.  It was also only a binary tree, potentially cutting garbage.  
However I recall each node occupying ~100 bytes, which is much more than the 
b-tree per-item overhead, and I recall it being slower to boot (meaning more 
overlapping operations)

You could try reducing the fan-factor in the b-tree to reduce the time of 
updates, and cost of failed updates, which might cause the behaviour to tend 
closer to that of a snaptree (e.g. a fan factor of 4 would average a ternary 
tree, as opposed to its current default of 16).

> 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