cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mck SembWever (Issue Comment Edited) (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (CASSANDRA-3427) CompressionMetadata is not shared across threads, we create a new one for each read
Date Sun, 13 Nov 2011 17:09:52 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-3427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149314#comment-13149314
] 

Mck SembWever edited comment on CASSANDRA-3427 at 11/13/11 5:08 PM:
--------------------------------------------------------------------

0.8 was running on Xmx8G up until week 44.
at that point we upgraded to 1.0 and enabled compression. The very high memory usage at the
beginning of week 44 was to handle the change from chunk_length 16 to 256.
Then for most of week 44 and week 45 we ran with Xmx16G, but this was very "squeezed". Now
that's OOM, and raising it to 20G didn't help. Currently it's on 30G.

Also note we're always used -XX:CMSInitiatingOccupancyFraction=60 for this cluster.
(full java opts are "-Xss128k -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42  -XX:SurvivorRatio=8
 -XX:MaxTenuringThreshold=1  -XX:+UseParNewGC  -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled
-XX:CMSInitiatingOccupancyFraction=60 -XX:+UseCMSInitiatingOccupancyOnly -Xmx30g -Xmx30g -Xmn800M
  -XX:ParallelCMSThreads=4  -XX:+CMSIncrementalMode  -XX:+CMSIncrementalPacing  -XX:CMSIncrementalDutyCycleMin=0
 -XX:CMSIncrementalDutyCycle=10". the last 5 were added during week 44 to try and help, ref
http://blog.mikiobraun.de/2010/08/cassandra-gc-tuning.html)
                
      was (Author: michaelsembwever):
    0.8 was running on Xmx8G up until week 44.
at that point we upgraded to 1.0 and enabled compression. The very high memory usage at the
beginning of week 44 was to handle the change from chunk_length 16 to 256.
Then for most of week 44 and week 45 we ran with Xmx16G, but this was very "squeezed". Now
that's OOM, and raising it to 20G didn't help. Currently it's on 30G.

Also note we're always used -XX:CMSInitiatingOccupancyFraction=60 for this cluster.
                  
> CompressionMetadata is not shared across threads, we create a new one for each read
> -----------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-3427
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3427
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.0
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>              Labels: compression
>             Fix For: 1.0.2
>
>         Attachments: 3427.patch, 3427_v2.patch, CASSANDRA-3427.patch, jmx_jvm_memory-month.png,
jmx_jvm_memory-week.png
>
>
> The CompressionMetada holds the compressed block offsets in memory. Without being absolutely
huge, this is still of non-negligible size as soon as you have a bit of data in the DB. Reallocating
this for each read is a very bad idea.
> Note that this only affect range queries, since "normal" queries uses CompressedSegmentedFile
that does reuse a unique CompressionMetadata instance.
> ( Background: http://thread.gmane.org/gmane.comp.db.cassandra.user/21362 )

--
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