Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 191E71014E for ; Thu, 7 Nov 2013 11:48:52 +0000 (UTC) Received: (qmail 78475 invoked by uid 500); 7 Nov 2013 11:48:47 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 78461 invoked by uid 500); 7 Nov 2013 11:48:45 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 78448 invoked by uid 99); 7 Nov 2013 11:48:43 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 Nov 2013 11:48:43 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of Ignace.Desimpel@nuance.com designates 198.71.66.80 as permitted sender) Received: from [198.71.66.80] (HELO som-mx-a.nuance.com) (198.71.66.80) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 Nov 2013 11:48:37 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4GAE59e1IKHBQY/2dsb2JhbABagkN8U78OgTxtB4InBS0yLAEVFVYmAQQbxTyPKINYgRADnnCOTIIq Received: from unknown (HELO SOM-CAS01.nuance.com) ([10.28.20.24]) by som-mx-a.nuance.com with ESMTP/TLS/AES128-SHA; 07 Nov 2013 06:48:09 -0500 Received: from SOM-EXCH02.nuance.com ([fe80::4992:8492:7315:6160]) by SOM-CAS01.nuance.com ([::1]) with mapi id 14.03.0158.001; Thu, 7 Nov 2013 06:48:15 -0500 From: "Desimpel, Ignace" To: "user@cassandra.apache.org" Subject: Endless loop LCS compaction Thread-Topic: Endless loop LCS compaction Thread-Index: Ac7bqevrXhejV/LeSMK670rsql8FsA== Date: Thu, 7 Nov 2013 11:48:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.16.110] Content-Type: multipart/alternative; boundary="_000_FCD5C460700DCA4C8CEB1730307336020782F9E6SOMEXCH02nuance_" MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org --_000_FCD5C460700DCA4C8CEB1730307336020782F9E6SOMEXCH02nuance_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tested on version 2.0.1 and 2.0.2. At complete idle running (nothing stored nor queried) I see that some rando= m (depending on the tests I do) column family gets compacted over and over = again (already 48h) . Total data size is only 3.5GB. Column family was crea= ted with SSTableSize : 10 MB Using some remote debugging I see (guess) that the loop is created due to s= ome extra code at LeveledManifest::getCompactionCandidates in an attempt to= use STCS if compaction gets behind (see code variable 'score'). In my case I get the following variables during execution (version 2.0.2) o= f LeveledManifest::getCompactionCandidates : level : 1 sstablesInLevel : 42 remaining : 42 total bytes for remaining : 448 MB max size for level : 100MB score 4.27 Due to score of 4.27 the code goes to special branch with variables during = execution (version 2.0.2) of LeveledManifest::getCompactionCandidates : Generations[0].size() : 77 Candidates : 77 Pairs : 77 Buckets : one list entry of 77 files mostInteresting : 32 files These 32 mostInteresting files are returned to the function LeveledCompacti= onStrategy::getMaximalTask, marked for compaction, and a new LeveledCompact= ionTask is created (Is it not the goal here to create an STCS task??) !! So then this task is doing its job, creating a new set of level 0 files, ea= ch of 10 MB. Thus again 32 files are created from the 32 files we started f= rom. So once the compaction loop restarts, it will do exactly the same thin= g again and again. Should an STCS task be created from within the LCS strategy? Or the optimiz= ation simply be removed? Ignace Desimpel --_000_FCD5C460700DCA4C8CEB1730307336020782F9E6SOMEXCH02nuance_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tested on version 2.0.1 and 2.0= .2.

 

At complete idle running (nothing stored nor queried= ) I see that some random (depending on the tests I do) column family gets c= ompacted over and over again (already 48h) . Total data size is only 3.5GB.= Column family was created with SSTableSize : 10 MB

 

Using some remote debugging I see (guess) that the l= oop is created due to some extra code at LeveledManifest::getCompactionCand= idates in an attempt to use STCS if compaction gets behind (see code variab= le ‘score’).

 

In my case I get the following variables during exec= ution (version 2.0.2) of LeveledManifest::getCompactionCandidates :

level : 1

sstablesInLevel : 42

remaining : 42

total bytes for remaini= ng : 448 MB

max size for level : 10= 0MB

score 4.27

Due to score of 4.27 the code goes to special branch= with variables during execution (version 2.0.2) of LeveledManifest::getCom= pactionCandidates :

        &nbs= p;       Generations[0].size() : 77

        &nbs= p;       Candidates : 77

        &nbs= p;       Pairs : 77

Buckets : one list entr= y of 77 files

mostInteresting : 32 fi= les

 

These 32 mostInteresting files are returned to the f= unction LeveledCompactionStrategy::getMaximalTask, marked for compaction, a= nd a new LeveledCompactionTask is created (Is it not the goal here to creat= e an STCS task??) !!

 

So then this task is doing its job, creating a new s= et of level 0 files, each of 10 MB. Thus again 32 files are created from th= e 32 files we started from. So once the compaction loop restarts, it will d= o exactly the same thing again and again.

 

Should an STCS task be created from within the LCS s= trategy? Or the optimization simply be removed?

 

Ignace Desimpel

 

 

--_000_FCD5C460700DCA4C8CEB1730307336020782F9E6SOMEXCH02nuance_--