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 6058518032 for ; Sat, 16 Jan 2016 09:42:59 +0000 (UTC) Received: (qmail 84826 invoked by uid 500); 16 Jan 2016 09:42:56 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 84782 invoked by uid 500); 16 Jan 2016 09:42:56 -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 84772 invoked by uid 99); 16 Jan 2016 09:42:56 -0000 Received: from Unknown (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 16 Jan 2016 09:42:56 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 51358C1261 for ; Sat, 16 Jan 2016 09:42:56 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.9 X-Spam-Level: *** X-Spam-Status: No, score=3.9 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_REPLY=1, HTML_MESSAGE=3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id DRC8mLdNhk-F for ; Sat, 16 Jan 2016 09:42:45 +0000 (UTC) Received: from mail-yk0-f180.google.com (mail-yk0-f180.google.com [209.85.160.180]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id 5774131ABE for ; Sat, 16 Jan 2016 09:42:44 +0000 (UTC) Received: by mail-yk0-f180.google.com with SMTP id v14so474980676ykd.3 for ; Sat, 16 Jan 2016 01:42:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=ZzZ+lLgynLhaVLp/E+lQqaB2ex3V9xaRKEpHSWHVAxU=; b=T8g2uiKQUPR395YYfx8ICLVrgGT1Qos3wTV4+E7IdGV57iezeHrCHecmoipSX5bE47 Bx6s0lX3SQstuWKIg8rjiWu0hQGJn3pJPPDyPcoshqNQdKYFuFqbmqj5I921nHCmiUDz y15dMUqTkEEmGYctyxVHQBY1QGt8wvSxxOBMbuh1GqM2S8KEmZuwVnPpI4fiErIhLnwW TpXqlKu9602pba7Xo4WWJdpExE6KJ565LvDRQJZQQNCplNycBRbG71F9NFa8HvVf3vFd H3TTv58Z5WBpNWWcSJY2PQn9jynXXtkT/Hka8ADS8oFRdkrZZVMaHvHjWxU9HI2QZ+F6 6ReA== 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:from:date :message-id:subject:to:content-type; bh=ZzZ+lLgynLhaVLp/E+lQqaB2ex3V9xaRKEpHSWHVAxU=; b=WzPZzetXysYF7LBx4fSGkPS7HvRiqaphy4fGYNXxPNvHBzT4c79wG+UheakJRRw7IA yGmr5XQ9vadlao0tffjdhhN4mU9tu/ODU5UW9p/FMrMb9cMBcBXpW8mFLn/WLeBWMOLt oNkTfvo36lIF7bmdHLe4GmoLlo53Gb4OBSadIbXFS1zuxGUjBRm1VVZsA8CaHc8quCsr Ndr1IXfauYYkLAEc984kBXzxDSyDGVADYm3I+FcVDw4QcnIP7UZ09a5bkghtsVvXaO3t TOqy1tVWekBwR2+6U+ZFUGynoraofU4NMgb/ykk6n0UCEmhw2rGz+EL3WZNSw1wiguxL q0eA== X-Gm-Message-State: ALoCoQk1Pu8S5hTJ/M4X+5+MetilsimiFKQGMyeFlkfE+oyULHciPgiSGKHAxjrv4E79GyRhyDt5ayfYc4+VpUIFCxWvCGVZAw== X-Received: by 10.129.48.193 with SMTP id w184mr10469192yww.238.1452937363343; Sat, 16 Jan 2016 01:42:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.83.214 with HTTP; Sat, 16 Jan 2016 01:42:23 -0800 (PST) In-Reply-To: References: From: DuyHai Doan Date: Sat, 16 Jan 2016 10:42:23 +0100 Message-ID: Subject: Re: Too many compactions, maybe keyspace system? To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=001a11414e826c589005297057c4 --001a11414e826c589005297057c4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Interesting, maybe it worths filing a JIRA. Empty tables should not slow down compaction of other tables On Sat, Jan 16, 2016 at 10:33 AM, Shuo Chen wrote: > Hi, Robert, > > I think I found the cause of the too many compactions. I used jmap to dum= p > the heap and used Eclipse memory analyzer plugin to extract the heap. > > In previous reply, It shows the there are too many pending jobs in the > Blocking queue. I checked the cf of the compaction task object. There are > many cfs concerning some empty cfs I created before. > > I created 5 keyspaces and about 100 cfs months by cassandra-cli ago and > didnot put any data yet. In fact, there is only 1 keypaces I created > containing data and the other 5 keyspaces are empty. > > When I droped these 5 keyspaces and restarted the high compaction node, I= t > runs normally with normal mount of compactions. > > So maybe there are some bugs of compaction for empty columnfamily? > > On Wed, Jan 13, 2016 at 2:39 AM, Robert Coli wrote= : > >> On Mon, Jan 11, 2016 at 9:12 PM, Shuo Chen wrote= : >> >>> I have a assumption that, lots of pending compaction tasks jam the >>> memory and raise full gc. The full chokes the process and slows down >>> compaction. And this causes more pending compaction tasks and more pres= sure >>> on memory. >>> >> >> The question is why there are so many pending compactions, because your >> log doesn't show that much compaction is happening. What keyspaces / >> columnfamilies do you expect to be compacting, and how many SSTables do >> they contain? >> >> >>> Is there a method to list the concrete details of pending compaction >>> tasks? >>> >> >> Nope. >> >> For the record, this type of extended operational debugging is often bes= t >> carried out interactively on #cassandra on freenode IRC.. :) >> >> =3DRob >> > > > > -- > *=E9=99=88=E7=A1=95* *Shuo Chen* > chenatu2006@gmail.com > chenshuo@whaty.com > --001a11414e826c589005297057c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Interesting, maybe it worths filing a JIRA. Empty tables s= hould not slow down compaction of other tables

On Sat, Jan 16, 2016 at 10:33 AM, Shuo C= hen <chenatu2006@gmail.com> wrote:
Hi, Robert,

I think I fo= und the cause of the too many compactions. I used jmap to dump the heap and= used Eclipse memory analyzer plugin to extract the heap.

In previous reply, It shows the there are too many pending jobs in = the Blocking queue. I checked the cf of the compaction task object. There a= re many cfs concerning some empty cfs I created before.

I created 5 keyspaces and about 100 cfs months by cassandra-cli ago a= nd didnot put any data yet. In =C2=A0fact, there is only 1 keypaces I creat= ed containing data and the other 5 keyspaces are empty.

When I droped these 5 keyspaces and restarted the high compaction nod= e, It runs normally with normal mount of compactions.

<= div>So maybe there are some bugs of compaction for empty columnfamily?

On Wed, Jan 13, 2016 at 2:39 AM, Robert Coli <rcoli@eventb= rite.com> wrote:
On Mon= , Jan 11, 2016 at 9:12 PM, Shuo Chen <chenatu2006@gmail.com> wrote:
I have a ass= umption that, lots of pending compaction tasks jam the memory and raise ful= l gc. The full chokes the process and slows down compaction. And this cause= s more pending compaction tasks and more pressure on memory.

The question is why there are so many pendin= g compactions, because your log doesn't show that much compaction is ha= ppening. What keyspaces / columnfamilies do you expect to be compacting, an= d how many SSTables do they contain?
=C2=A0
Is there a method to list the co= ncrete details of pending compaction tasks?
Nope.=C2=A0

For the record, th= is type of extended operational debugging is often best carried out interac= tively on #cassandra on freenode IRC.. :)

=3DRob



--
=E9=99=88=E7=A1=95 Shuo Chenchenshuo@whaty.co= m

--001a11414e826c589005297057c4--