[
https://issues.apache.org/jira/browse/CASSANDRA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716299#action_12716299
]
Jonathan Ellis commented on CASSANDRA-208:
------------------------------------------
Jiansheng: can you give us more details about your data set? We are trying to
figure out how likely it is for others to run into this, leaning towards moving
this patch to trunk/0.4.
The relevant data are
- how many keys in the CF that fails to compact
- average / max row size (column size x count) in that CF
- jvm memory settings, and how much of the heap is free (according to e.g.
jconsole) before compaction starts
> OOM intermittently during compaction
> ------------------------------------
>
> Key: CASSANDRA-208
> URL: https://issues.apache.org/jira/browse/CASSANDRA-208
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: trunk
> 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.3
>
> Attachments: 0001-CASSANDRA-208-cleanup.txt,
> 0002-r-m-touch-code-that-populates-a-cache-that-is-never.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.
