[
https://issues.apache.org/jira/browse/CASSANDRA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716472#action_12716472
]
Jonathan Ellis commented on CASSANDRA-208:
------------------------------------------
1. empty memtables are not flushed, so there will be at least one key, and the
first key will always be in indexEntries since 0 % interval == 0 for any
interval. lots of the tests have only one row. I don't think there is a
problem here.
2. ok
3. Hmm, if you have columns B C and D in a row, and you do a slice_from
starting with A, don't you want B C D to be returned? getNearestPosition will
start the scan at B, but vanilla getPosition will return -1 if there is not an
exact match.
> OOM intermittently during compaction
> ------------------------------------
>
> Key: CASSANDRA-208
> URL: https://issues.apache.org/jira/browse/CASSANDRA-208
> Project: Cassandra
> Issue Type: Bug
> Environment: arch: x86_64
> os: Linux version 2.6.18-92.1.22.el5
> java: nio2-ea-bin-b99-linux-x64-05_feb_2009
> Reporter: Jiansheng Huang
> Assignee: Jonathan Ellis
> Priority: Critical
> Fix For: 0.4
>
> Attachments: 0001-CASSANDRA-208-cleanup.txt, 0002-r-m-touch.txt,
> 0003-split-sstable-into-data-index-and-bloom-filter-files.txt
>
>
> jvm crashes intermittently during compaction. Our test data set is not that
> big, less than 10 GB.
> When jvm is about to crash, we see that it consumes a lot of memory
> (exceeding the max heap size).
> The excessive memory usage during compaction is caused by the maintenance of
> blockIndexes_ in SSTable. this blockIndexes_ was only introduced to the
> apache version.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
