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 9209D17853 for ; Fri, 3 Apr 2015 20:06:57 +0000 (UTC) Received: (qmail 63031 invoked by uid 500); 3 Apr 2015 20:06:54 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 62987 invoked by uid 500); 3 Apr 2015 20:06:54 -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 62977 invoked by uid 500); 3 Apr 2015 20:06:53 -0000 Delivered-To: apmail-incubator-cassandra-user@incubator.apache.org Received: (qmail 62974 invoked by uid 99); 3 Apr 2015 20:06:53 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Apr 2015 20:06:53 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of tbsalling@tbsalling.dk designates 209.85.213.173 as permitted sender) Received: from [209.85.213.173] (HELO mail-ig0-f173.google.com) (209.85.213.173) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Apr 2015 20:06:29 +0000 Received: by igblo3 with SMTP id lo3so13064033igb.1 for ; Fri, 03 Apr 2015 13:04:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tbsalling.dk; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KlojqMqO6lHFDxPvK409sw3cYZ9bpLtazwiKc59SBRQ=; b=iBr30MWBSxjAX6G+ir+Sx9+HnUvtaIjIn8q1LDCwfSER3FsTPT9GfLfF1TgdjFG/BR XNxdPKjp00YF/lYpKXmKOOUkD1aePeKOUaF+H6VP46rCP9Fbo9EFfI26nTSVeRtKL16Z n7ySuI5xbv6ITw6dy70MIboxE5XNLzRPkf6vc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KlojqMqO6lHFDxPvK409sw3cYZ9bpLtazwiKc59SBRQ=; b=bwdP1D5Ytub4JQIsiDKgxFY0Cb3yMnUInw0Csk+wFHoBPA1jnFK0/9o6GP1H3x9Q/l SsgTsnXisnRhTc0RqCRmd7rM3EK+dXjIlDHxFw0DhcqJ2rYberhm+3NHWy9O0jlBhl67 dxBUn0s4k21LqA75TA8rMMW0pPYeMVPUEzvk8BtxM+CCSfOX8kA/3gqmXpoDt7OEHSWv RUQafY1xM2rFX4GvfnafRWHbC8OpjqUBI53KUvtM9F7hVv6/MndFhMfQcOC7OZ7hvbyT LSSYo72OA2p2laAbfqc68+3mSRQwYu5+wLEcAaYFypxbTVVUSU/Lpb34ZjhRwyZk0HwH rgXg== X-Gm-Message-State: ALoCoQl4A+OORItluWQ2cMVV0LFHGFpncg+hrokZkDzArkuhPUUKLCuzH4dZOBtsxDG2vePzpWQN MIME-Version: 1.0 X-Received: by 10.50.111.10 with SMTP id ie10mr30245685igb.15.1428091496819; Fri, 03 Apr 2015 13:04:56 -0700 (PDT) Received: by 10.107.6.14 with HTTP; Fri, 3 Apr 2015 13:04:56 -0700 (PDT) In-Reply-To: References: Date: Fri, 3 Apr 2015 22:04:56 +0200 Message-ID: Subject: Re: Huge number of sstables after adding server to existing cluster From: Thomas Borg Salling To: user@cassandra.apache.org Cc: cassandra-user@incubator.apache.org Content-Type: multipart/alternative; boundary=089e0149c05460062d0512d77608 X-Virus-Checked: Checked by ClamAV on apache.org --089e0149c05460062d0512d77608 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with Pranay. I have experienced exactly the same on C* 2.1.2. /Thomas. 2015-04-03 19:33 GMT+02:00 Pranay Agarwal : > I remember once that happening to me. The SStables were way beyond the > limit (32 default) but the compaction were still not starting. All I did > was "nodetool enableautocompaction keyspace table" and the compaction > immediately started and count of SSTables were down to normal level. It w= as > little surprising to me as well because I had never disabled compaction i= n > the first place. > > -Pranay > > On Fri, Apr 3, 2015 at 10:18 AM, Robert Coli wrote= : > >> On Fri, Apr 3, 2015 at 4:57 AM, Mantas Klasavi=C4=8Dius < >> mantas.klasavicius@gmail.com> wrote: >> >>> Q1:is that what we should expect to happen? >>> >> A known problem with the current streaming paradigm when combined with >> vnodes is that newly bootstrapped nodes do a bunch of compaction. >> >> >>> Q2:what could be the reason of not reducing number of sstables? >>> >> nodetool setcompactionthroughput 0 # note, if you don't have spare i/o, >> this could negatively affect service time >> >> >>> Q3:what we need to do to reduce number of sstables per server? >>> >> Make sure you're compacting faster than you're writing and wait. >> >> =3DRob >> http://twitter.com/rcolidba >> > > --089e0149c05460062d0512d77608 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with Pranay. I have experienced exactly the same o= n C* 2.1.2.
/Thomas.

2015-04-03 19:33 GMT+02:00 Pranay Agarwal <agarwalpranaya@gmail.com>:
I remember once that happening to me. The SStables = were way beyond the limit (32 default) but the compaction were still not st= arting. All I did was "nodetool enableautocompaction keyspace table&qu= ot; and the compaction immediately started and count of SSTables were down = to normal level. It was little surprising to me as well because I had never= disabled compaction in the first place.

-Pranay=C2=A0

On Fri, Apr 3, 2015 at 10:18 AM, Robert Coli <rcol= i@eventbrite.com> wrote:
= On Fri, Apr 3, 2015 at 4:57 AM, Mantas Klasavi=C4=8Dius &= lt;mantas= .klasavicius@gmail.com> wrote:

Q1:is that what we should expect to happ= en?

A known problem with the current stre= aming paradigm when combined with vnodes is that newly bootstrapped nodes d= o a bunch of compaction.
=C2=A0

Q2:what could be the reason of not = reducing number of sstables?

nodetool set= compactionthroughput 0 # note, if you don't have spare i/o, this could = negatively affect service time
=C2=A0

Q3:what we need to do to redu= ce number of sstables per server?

Make su= re you're compacting faster than you're writing and wait.

=3DRob


--089e0149c05460062d0512d77608--