Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 12 Oct 2017 17:27:00 +0000 (UTC)
From: "Marcus Eriksson (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.13108030.1507569782000.42619.1507829220544@Atlassian.JIRA>
In-Reply-To: <JIRA.13108030.1507569782000@Atlassian.JIRA>
References: <JIRA.13108030.1507569782000@Atlassian.JIRA> <JIRA.13108030.1507569782896@jira-lw-us.apache.org>
Subject: [jira] [Commented] (CASSANDRA-13943) Infinite compaction of L0
 SSTables in JBOD
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 12 Oct 2017 17:27:06 -0000


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

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

but not seeing any infinite compactions in the logs anymore?

and could you post your cassandra.yaml and describe how much data you are writing?

> 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: cassandra-jstack-2017-10-12.txt, debug.log, debug.log-with-commit-d8f3f2780
>
>
> 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: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org