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 233B29564 for ; Fri, 23 Sep 2011 05:41:15 +0000 (UTC) Received: (qmail 63094 invoked by uid 500); 23 Sep 2011 05:41:13 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 63033 invoked by uid 500); 23 Sep 2011 05:41:11 -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 63009 invoked by uid 99); 23 Sep 2011 05:41:10 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 23 Sep 2011 05:41:10 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of watcherfr@gmail.com designates 74.125.82.172 as permitted sender) Received: from [74.125.82.172] (HELO mail-wy0-f172.google.com) (74.125.82.172) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 23 Sep 2011 05:41:04 +0000 Received: by wyh21 with SMTP id 21so1518767wyh.31 for ; Thu, 22 Sep 2011 22:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=LPzMjFCf/Y3itxrb5eSgCh0ahpeC21Lh/XTaB3geaAo=; b=SrIIoSYl7TlWGYGytlzmCUAEMb3bhSfK1Mahj0ES1NfVG4H/MFWIGCjfNKAjbDBQq/ cxObe8ZspQNE/gQFYn24iCUkQx4ADFr+rP4WzCnV7fCf//5fHvmozQ/UFBML0GBd3q/r l0EMjdOjbfKarFFHc79g7LwiKAvp7uNmy7LTc= MIME-Version: 1.0 Received: by 10.227.19.203 with SMTP id c11mr3014200wbb.107.1316756443051; Thu, 22 Sep 2011 22:40:43 -0700 (PDT) Received: by 10.180.8.228 with HTTP; Thu, 22 Sep 2011 22:40:43 -0700 (PDT) Received: by 10.180.8.228 with HTTP; Thu, 22 Sep 2011 22:40:43 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 Sep 2011 07:40:43 +0200 Message-ID: Subject: Re: is it possible for light-traffic CF to hold down many commit logs? From: Philippe To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=002215b02f9a0b35d804ad954069 --002215b02f9a0b35d804ad954069 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It sure looks like what I'm seeing on my cluster where a 100G commit lot partition fills up in 12 hours (0.8.x) Le 23 sept. 2011 03:45, "Yang" a =E9crit : > in 1.0.0 we don't have memtable_throughput for each individual CF , > and instead > which memtable/CF to flush is determined by "largest > getTotalMemtableLiveSize() ". > (MeteredFlusher.java line 81) > > > what would happen in the following case ? : I have only 2 CF, the > traffic for one CF is 1000 times that > of the second CF, > so the high-traffic CF constantly triggers total mem threshold , and > every time, the busy CF is flushed. > > but the light-traffic CF is never flushed ( well, until we have > flushed about 1000 times the busy CF), > now we are left with many commit logs , each of them containing a few > entries for the light-traffic table. we have to keep these commit logs > because these entries are not flushed to sstable yet. > > then there are 2 problems: 1) to persist the few records from the > light-traffic CF, you have to keep 1000 times the commit logs > necessary, taking up disk space 2) when you do a recover on server > restart, you'll have to read through all those commit logs . > > does the above hypothesis sound right? > > Thanks > Yang --002215b02f9a0b35d804ad954069 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

It sure looks like what I'm seeing on my cluster where a 100G commit= lot partition fills up in 12 hours (0.8.x)

Le 23 sept. 2011 03:45, "Yang" <teddyyyy123@gmail.com> a =E9cr= it=A0:
> in 1.0.0 we don't have memtable_th= roughput for each individual CF ,
> and instead
> which memtable/CF to flush is determined by "= largest
> getTotalMemtableLiveSize() ".
> (MeteredFlusher.= java line 81)
>
>
> what would happen in the following = case ? : I have only 2 CF, the
> traffic for one CF is 1000 times that
> of the second CF,
>= ; so the high-traffic CF constantly triggers total mem threshold , and
&= gt; every time, the busy CF is flushed.
>
> but the light-traf= fic CF is never flushed ( well, until we have
> flushed about 1000 times the busy CF),
> now we are left with ma= ny commit logs , each of them containing a few
> entries for the ligh= t-traffic table. we have to keep these commit logs
> because these en= tries are not flushed to sstable yet.
>
> then there are 2 problems: 1) to persist the few records from= the
> light-traffic CF, you have to keep 1000 times the commit logs<= br>> necessary, taking up disk space 2) when you do a recover on server<= br> > restart, you'll have to read through all those commit logs .
&g= t;
> does the above hypothesis sound right?
>
> Thanks<= br>> Yang
--002215b02f9a0b35d804ad954069--