cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-12668) Memtable Contention in 2.1
Date Mon, 19 Sep 2016 21:28:21 GMT


Benedict commented on CASSANDRA-12668:

Come on, let's avoid hyperbole.

Lower throughput != unusable, and if you were to reduce the size of your memtables the increased
GC burden would probably be coped with too.  Everything is about trade-offs, as was the swapping
of the data structure in the first place.  There's rarely a 100% free lunch.

Still, much more information is needed before anything informative can be said.  You've still
given very few details; we still have nothing about the size of the partitions, their number,
the rate of updates (total and per partition), the size of the datums, the total size provided
for the memtables.  The configuration parameters such as flush queue size, memtable_cleanup_threshold
and concurrent_writes.  No profiling information, no heap numbers.  Just some fairly broad
qualitative/correlative statements.

> Memtable Contention in 2.1
> --------------------------
>                 Key: CASSANDRA-12668
>                 URL:
>             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

View raw message