You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Ryan McGuire (JIRA)" <ji...@apache.org> on 2013/05/02 21:02:15 UTC
[jira] [Comment Edited] (CASSANDRA-5534) Writing wide row causes
high CPU usage after compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13647815#comment-13647815 ]
Ryan McGuire edited comment on CASSANDRA-5534 at 5/2/13 7:00 PM:
-----------------------------------------------------------------
The reason I titled this bug with the phrase "after compaction" is that the very last line of the log file that talked about compaction 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.
was (Author: enigmacurry):
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