[ 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)