[
https://issues.apache.org/jira/browse/CASSANDRA-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-2301:
--------------------------------------
Attachment: 2301-v2.txt
I'm actually not sure how this could help -- dfile.close() already
un-references the buffer, so there's no need to set dfile itself to be null.
Also, the file pointer changes as we read through the file, so changing
bytescomplete to init-once is broken. (This is what nodetool compactionstats
uses.)
My guess is that the second time around you just got lucky and index build was
able to keep up w/ streaming enough to avoid OOMing.
But there is a bug here with the file/buffer handling -- we should lazy-init
this once we're ready to build the index, rather than when we enqueue the task.
Patch attached w/ this approach.
> OOM on repair with many inconsistent ranges
> -------------------------------------------
>
> Key: CASSANDRA-2301
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2301
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.7.0
> Reporter: Joaquin Casares
> Assignee: Joaquin Casares
> Fix For: 0.7.4
>
> Attachments: 2301-v2.txt, 2301.diff
>
>
> Repair can OOM when lots of ranges are inconsistent, causing many sstables to
> be streamed.
> I replicated the error by making 1264 3MB sstables on one node, added a
> second node, changed the replication factor to 2, and ran a repair.
> Looking at the heap dump of the original failure, there were 2.4GB of
> FutureTasks, each taking up 8MB of space. I tracked down the
> BufferedRandomAccessFile and made sure that it was cleared every time it was
> closed inside of src/java/org/apache/cassandra/io/sstable/SSTableWriter.java.
> Attached is the patch I used which stopped the error when I was trying to
> replicate it.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
