Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 2 May 2013 19:00:17 +0000 (UTC)
From: "Ryan McGuire (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12645855.1367520782032.261817.1367521217150@arcas>
In-Reply-To: <JIRA.12645855.1367520782032@arcas>
References: <JIRA.12645855.1367520782032@arcas>
Subject: [jira] [Commented] (CASSANDRA-5534) Writing wide row causes high
 CPU usage after compaction
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Ryan McGuire commented on CASSANDRA-5534:
-----------------------------------------

The reason I titled this bug with the phrase "after compaction" is that the very last line of the log file that talked about copaction is what it stayed on for the majority of that 4 minutes that it ran for. I don't have any other clues that this is related to compaction. 
                
> Writing wide row causes high CPU usage after compaction
> -------------------------------------------------------
>
>                 Key: CASSANDRA-5534
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5534
>             Project: Cassandra
>          Issue Type: Bug
>    Affects Versions: 2.0
>            Reporter: Ryan McGuire
>            Assignee: Jonathan Ellis
>         Attachments: wide_row_stress.trunk.log.txt.gz
>
>
> Introduced in commit e74c13ff08663d306dcc5cdc99c07e9e6c12ca21 there is a significant slow down when creating a wide row with cassandra-stress:
> Testing with the prior (good) commit I used this to write a single wide row, which completed rather quickly:
> {code}
> $ ccm create -v git:60f09f0121e0801851b9ab017eddf7e326fa05fb wide-row
> Fetching Cassandra updates...
> Cloning Cassandra (from local cache)
> Checking out requested branch (60f09f0121e0801851b9ab017eddf7e326fa05fb)
> Compiling Cassandra 60f09f0121e0801851b9ab017eddf7e326fa05fb ...
> Current cluster is now: wide-row
> $ ccm populate -n 1
> $ ccm start
> $ time ccm node1 stress -c 10000 -S 1000 -n 1
> Created keyspaces. Sleeping 1s for propagation.
> total,interval_op_rate,interval_key_rate,latency/95th/99th,elapsed_time
> 1,0,0,273.3,273.3,273.3,0
> END
> real	0m7.106s
> user	0m1.710s
> sys	0m0.120s
> {code}
> Using the bugged commit (e74c13ff08663d306dcc5cdc99c07e9e6c12ca21) I get a significant slow down:
> {code}
> 02:42 PM:~$ ccm create -v git:e74c13ff08663d306dcc5cdc99c07e9e6c12ca21 wide-row
> Fetching Cassandra updates...
> Current cluster is now: wide-row
> 02:42 PM:~$ ccm populate -n 1
> 02:42 PM:~$ ccm start
> 02:42 PM:~$ time ccm node1 stress -c 10000 -S 1000 -n 1
> Created keyspaces. Sleeping 1s for propagation.
> total,interval_op_rate,interval_key_rate,latency,95th,99th,elapsed_time
> 1,0,0,423.2,423.2,423.2,0
> Total operation time      : 00:00:00
> END
> real	4m16.394s
> user	0m2.230s
> sys	0m0.137s
> {code}
> Interestingly, the commit in question just says it's a merge from cassandra-1.2, but I do not see this same slowdown using that branch, this only occurs in trunk.

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