[jira] [Issue Comment Edited] (CASSANDRA-3427) CompressionMetadata is not shared across threads, we create a new one for each read

["Mck SembWever (Issue Comment Edited) (JIRA)" <ji...@apache.org>]

    [ 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