[
https://issues.apache.org/jira/browse/CASSANDRA-5344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13617824#comment-13617824
]
Jonathan Ellis commented on CASSANDRA-5344:
-------------------------------------------
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
