[
https://issues.apache.org/jira/browse/CASSANDRA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716359#action_12716359
]
Jiansheng Huang commented on CASSANDRA-208:
-------------------------------------------
To answer Jonathan's questions: (1) we have tested around several million keys,
(2) avg row size ~ 2k, max row size ~ 10k. (3) tried several Xmx settings, max
tried is 5G. Before compaction starts, pretty much most of the heap is free. I
think the problem is easy to run into if the system is run with continuous
traffic for over a week or so.
> 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-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.
