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

Marcus Eriksson commented on CASSANDRA-10643:
---------------------------------------------

I tried it out but it wasn't doing any compaction if it had cancelled 
compactions - reason is that we have the wrong sstable reader instances.

I pushed a few commits 
[here|https://github.com/krummas/cassandra/commits/vkasar/10643] which 
rearranges the code a bit to cancel the compactions before we pick the sstables

Could you have a look?

It also makes sure that single-sstable user defined compactions can stay in the 
same level as it was before the compaction

Test runs:
http://cassci.datastax.com/view/Dev/view/krummas/job/krummas-vkasar-10643-dtest/
http://cassci.datastax.com/view/Dev/view/krummas/job/krummas-vkasar-10643-testall/

> Implement compaction for a specific token range
> -----------------------------------------------
>
>                 Key: CASSANDRA-10643
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10643
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Compaction
>            Reporter: Vishy Kasar
>            Assignee: Vishy Kasar
>              Labels: lcs
>         Attachments: 10643-trunk-REV01.txt, 10643-trunk-REV02.txt, 
> 10643-trunk-REV03.txt
>
>
> We see repeated cases in production (using LCS) where small number of users 
> generate a large number repeated updates or tombstones. Reading data of such 
> users brings in large amounts of data in to java process. Apart from the read 
> itself being slow for the user, the excessive GC affects other users as well. 
> Our solution so far is to move from LCS to SCS and back. This takes long and 
> is an over kill if the number of outliers is small. For such cases, we can 
> implement the point compaction of a token range. We make the nodetool compact 
> take a starting and ending token range and compact all the SSTables that fall 
> with in that range. We can refuse to compact if the number of sstables is 
> beyond a max_limit.
> Example: 
> nodetool -st 3948291562518219268 -et 3948291562518219269 compact keyspace 
> table



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to