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] [Commented] (CASSANDRA-5344) Make LCR less memory-abusive
Date Wed, 13 Mar 2013 22:14:14 GMT

    [ 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

Mime
View raw message