cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-5344) Make LCR less memory-abusive
Date Fri, 29 Mar 2013 22:33:16 GMT

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

Jonathan Ellis edited comment on CASSANDRA-5344 at 3/29/13 10:32 PM:
---------------------------------------------------------------------

I'd forgotten that we want to hang onto that index entry anyway, so we can preheat the cache
if necessary.  We can mostly-solve this, by checking if we're going to need the entry ahead
of time (most of the time, we won't), and pushing that information into append/write.

At this point I've mostly implemented single-pass compaction (CASSANDRA-4180) as a byproduct
of trying to solve this, so I think I'll finish that first before coming back to this.
                
      was (Author: jbellis):
    This has two problems:

Hmm, I'd forgotten that we want to hang onto that index entry anyway, so we can preheat the
cache if necessary.  We can mostly-solve this, by checking if we're going to need the entry
ahead of time (most of the time, we won't), and pushing that information into append/write.

At this point I've mostly implemented single-pass compaction (CASSANDRA-4180) as a byproduct
of trying to solve this, so I think I'll finish that first before coming back to this.
                  
> Make LCR less memory-abusive
> ----------------------------
>
>                 Key: CASSANDRA-5344
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5344
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Jonathan Ellis
>            Priority: Minor
>
> We've seen several reports of compaction causing GC pauses.  You would think this would
be the fault of PCR (which materializes the rows in memory) but LCR seems to be more of a
problem.
> I hypothesize that PCR mostly generates just young-gen garbage, but since LCR keeps the
BF and row index in-memory for a long time (from construction, until after the row has been
merged and written), it gets tenured and can cause fragmentation or promotion failures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message