cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack Krupansky (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-9754) Make index info heap friendly for large CQL partitions
Date Tue, 09 Feb 2016 20:34:18 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-9754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139712#comment-15139712
] 

Jack Krupansky commented on CASSANDRA-9754:
-------------------------------------------

bq. large CQL partitions (4GB,75GB,etc)

What is the intended target/sweet spot for large partitions... 1GB, 2GB, 4GB, 8GB, 10GB, 15GB,
16GB, or... what? Will random access to larger partitions create any significant heap/off-heap
memory demand, or will heap/memory simply become the total rows accessed regardless of how
they might be bucketed into partitions?

Will we be able to tell people that bucketing of partitions is now never needed, or will there
now just be a larger bucket size, like 4GB/partition rather than the 10MB or 50MB or 100MB
that some of us recommend today?

> Make index info heap friendly for large CQL partitions
> ------------------------------------------------------
>
>                 Key: CASSANDRA-9754
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9754
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: sankalp kohli
>            Assignee: Michael Kjellman
>            Priority: Minor
>
>  Looking at a heap dump of 2.0 cluster, I found that majority of the objects are IndexInfo
and its ByteBuffers. This is specially bad in endpoints with large CQL partitions. If a CQL
partition is say 6,4GB, it will have 100K IndexInfo objects and 200K ByteBuffers. This will
create a lot of churn for GC. Can this be improved by not creating so many objects?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message