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

Cyril Scetbon commented on CASSANDRA-6614:
------------------------------------------

I found that using "nodetool drain" prevents from having this issue. However 
"nodetool drain" should only prevent overcounts of counter data and make the 
restart faster. And why only with the first node and not with others (maybe 
system column families have been flushed on others ??)
[~jasobrown], did you use "nodetool drain" ?

> 2 hours loop flushing+compacting 
> system/{schema_keyspaces,schema_columnfamilies,schema_columns} when upgrading
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-6614
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6614
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>         Environment: ubuntu 12.04
>            Reporter: Cyril Scetbon
>
> It happens when we upgrade one node to 1.2.13 on a 1.2.2 cluster 
> see http://pastebin.com/YZKUQLXz
> If I grep for only InternalResponseStage logs I get 
> http://pastebin.com/htnXZCiT which always displays same account of ops and 
> serialized/live bytes per column family.
> When I upgrade one node from 1.2.2 to 1.2.13, for 2h I get the previous 
> messages with a raise of CPU (as it flushes and compacts continually) on all 
> nodes 
> http://picpaste.com/pics/Screen_Shot_2014-01-24_at_09.18.50-ggcCDVqd.1390587562.png
> After that, everything is fine and I can upgrade other nodes without any 
> raise of cpus load. when I start the upgrade, the more nodes I upgrade at the 
> same time (at the beginning), the higher the cpu load is 
> http://picpaste.com/pics/Screen_Shot_2014-01-23_at_17.45.56-I3fdEQ2T.1390587597.png



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Reply via email to