[
https://issues.apache.org/jira/browse/CASSANDRA-12668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15504578#comment-15504578
]
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
(v6.3.4#6332)
