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

Chris Eineke commented on CASSANDRA-5748:
-----------------------------------------

Sylvain,

Thank you for your response. That's great to hear! Is there a anticipated 
release date yet?
                
> When flushing, nodes spent almost 100% in AbstractCompositeType.compare
> -----------------------------------------------------------------------
>
>                 Key: CASSANDRA-5748
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5748
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.2.5, 1.2.6
>         Environment: Apache Cassandra v1.2.6
> 4-node cluster, mostly the same hardware
> # java -version
> java version "1.6.0_37"
> Java(TM) SE Runtime Environment (build 1.6.0_37-b06)
> Java HotSpot(TM) 64-Bit Server VM (build 20.12-b01, mixed mode)
>            Reporter: Chris Eineke
>            Priority: Critical
>         Attachments: thread_dump
>
>
> We're pretty heavy users of CQL3 and CQL3 collection types. Occasionally, 
> some nodes of the cluster will become extremely sluggish and the cluster as a 
> whole starts to become unresponsive, reads will time out, and nodes will drop 
> mutation messages. This happens when nodes flush Memtables to disk (based on 
> my tail of the system.log on each node).
> I'm a curious guy, so I attached jvisualvm (v1.3.3) to the JVMs that were 
> having this problem. These nodes are spending up to 98% of CPU in 
> org.apache.cassandra.db.marshal.AbstractCompositeType.compare(AbstractCompositeType.java:78).
>  I will attach a thread dump.
> Thi is causing us quite a headache, because we're unable to figure what would 
> be causing this. We tried tuning several configuration settings (column cache 
> size, row key cache size), but the cluster exhibits the same issues even with 
> the default configuration (except for a modified num_tokens and 
> listen_address).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to