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

Marcus Eriksson commented on CASSANDRA-13943:
---------------------------------------------

There is clearly a bug in the startsWith code, patch for that 
[here|https://github.com/krummas/cassandra/commits/marcuse/13943]

But since you have another subdirectory after the similar prefix, I don't think 
that is the problem here. Reading back some other issues - it seems you were 
running the (somewhat broken) patch from CASSANDRA-13215 for a while - is that 
still true on these nodes?

Could you start these nodes with a patch that logs a bit more?

> Infinite compaction of L0 SSTables in JBOD
> ------------------------------------------
>
>                 Key: CASSANDRA-13943
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13943
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Compaction
>         Environment: Cassandra 3.11.0 / Centos 6
>            Reporter: Dan Kinder
>            Assignee: Marcus Eriksson
>         Attachments: debug.log
>
>
> I recently upgraded from 2.2.6 to 3.11.0.
> I am seeing Cassandra loop infinitely compacting the same data over and over. 
> Attaching logs.
> It is compacting two tables, one on /srv/disk10, the other on /srv/disk1. It 
> does create new SSTables but immediately recompacts again. Note that I am not 
> inserting anything at the moment, there is no flushing happening on this 
> table (Memtable switch count has not changed).
> My theory is that it somehow thinks those should be compaction candidates. 
> But they shouldn't be, they are on different disks and I ran nodetool 
> relocatesstables as well as nodetool compact. So, it tries to compact them 
> together, but the compaction results in the exact same 2 SSTables on the 2 
> disks, because the keys are split by data disk.
> This is pretty serious, because all our nodes right now are consuming CPU 
> doing this for multiple tables, it seems.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to