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] [Resolved] (CASSANDRA-4142) OOM Exception during repair session with LeveledCompactionStrategy
Date Wed, 09 May 2012 20:01:49 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-4142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jonathan Ellis resolved CASSANDRA-4142.
---------------------------------------

    Resolution: Fixed

Added a special case for L0 in 67ed39fa9bf71be4cfc13fccbdd7b76dcb46c062.  Still getting errors.
 I think these are due to a pre-existing bug in LCS.  Opened CASSANDRA-4233 to follow up.
                
> OOM Exception during repair session with LeveledCompactionStrategy
> ------------------------------------------------------------------
>
>                 Key: CASSANDRA-4142
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4142
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.0.0
>         Environment: OS: Linux CentOs 6 
> JDK: Java HotSpot(TM) 64-Bit Server VM (build 14.0-b16, mixed mode)
> Node configuration:
> Quad-core
> 10 GB RAM
> Xmx set to 2,5 GB (as computed by default).
>            Reporter: Romain Hardouin
>            Assignee: Sylvain Lebresne
>             Fix For: 1.1.1
>
>         Attachments: 4142-v2.txt, 4142.txt
>
>
> We encountered an OOM Exception on 2 nodes during repair session.
> Our CF are set up to use LeveledCompactionStrategy and SnappyCompressor.
> These two options used together maybe the key to the problem.
> Despite of setting XX:+HeapDumpOnOutOfMemoryError, no dump have been generated.
> Nonetheless a memory analysis on a live node doing a repair reveals an hotspot: an ArrayList
of SSTableBoundedScanner which appears to contain as many objects as there are SSTables on
disk. 
> This ArrayList consumes 786 MB of the heap space for 5757 objects. Therefore each object
is about 140 KB.
> Eclipse Memory Analyzer's denominator tree shows that 99% of a SSTableBoundedScanner
object's memory is consumed by a CompressedRandomAccessReader which contains two big byte
arrays.
> Cluster information:
> 9 nodes
> Each node handles 35 GB (RandomPartitioner)
> This JIRA was created following this discussion:
> http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Why-so-many-SSTables-td7453033.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message