[
https://issues.apache.org/jira/browse/CASSANDRA-5344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601731#comment-13601731
]
Jonathan Ellis commented on CASSANDRA-5344:
-------------------------------------------
I took a stab at this in https://github.com/jbellis/cassandra/branches/5344, by
moving the index update into ACR.write. My plan was to then make the index
build go directly to disk. (BF would build in memory, but write to disk as
soon as it was done.)
isEmpty stymied me, though -- it basically requires that we do a pass first
that doesn't write anything, before we can do the real work.
Hoping [~jasobrown] or [~yukim] might have some ideas...
> 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
