[
https://issues.apache.org/jira/browse/CASSANDRA-12668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15504466#comment-15504466
]
Benedict commented on CASSANDRA-12668:
--------------------------------------
Did configuring 7546 to *always* synchronous behaviour not resolve the problem?
If not, it doesn't seem like contention was the problem.
The decline in write performance from contention is somewhat unrelated to GC -
certainly it will produce a GC burden, but that's only a small portion of its
effect. The B-Tree can incur a higher GC overhead anyway, also, although in
reality I would expect it to be hard to spot.
What makes you pin the blame here specifically? Is the only indication GC
failure?
There were of course many other changes in 2.1 that could be impacting things
wrt GC. Something as simple as memtable space being accurately calculated may
now be putting your heap under increased pressure than it had been under 2.0
(which may have never successfully calculated its multiplier - this was quite
common - in which case memtable occupancy was a fraction of that specified)
All things considered, a bit more investigation (or information from your
investigation) is needed before anything can helpfully be said.
> 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)
