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 817239E22 for ; Thu, 12 Apr 2012 07:55:38 +0000 (UTC) Received: (qmail 65851 invoked by uid 500); 12 Apr 2012 07:55:36 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 65739 invoked by uid 500); 12 Apr 2012 07:55:33 -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 65711 invoked by uid 99); 12 Apr 2012 07:55:32 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Apr 2012 07:55:32 +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: local policy) Received: from [194.126.128.137] (HELO cer31mx21.cirso.fr) (194.126.128.137) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Apr 2012 07:55:26 +0000 X-PJ: In-Reply-To: <7140D00C-77E9-47A6-8375-F827E41B12F0@gmail.com> To: user@cassandra.apache.org Subject: Re: Why so many SSTables? MIME-Version: 1.0 From: Romain HARDOUIN Message-ID: Date: Thu, 12 Apr 2012 09:54:04 +0200 Content-Type: multipart/alternative; boundary="=_alternative 002B7D6BC12579DE_=" X-Virus-Checked: Checked by ClamAV on apache.org Message en plusieurs parties au format MIME --=_alternative 002B7D6BC12579DE_= Content-Type: text/plain; charset="US-ASCII" I've just opened a new JIRA: CASSANDRA-4142 I've double checked numbers, 7747 seems to be array list object's capacity (Eclipse Memory Analyzer displays "java.lang.Object[7747] @ 0x7d3f3f798"). Actually there are 5757 browsable entries in EMA therefore each object is about 140 KB (size varies between 143088 bits and 143768 bits). We have no pending compactions tasks. Our cluster is currently under-loaded. Our goal is to handle hundreds of tera bytes which explains 1 TB per node. Our need is to archive data so our cluster is not running under a read-heavy load. @Dave Brosius: I made a mistake. To be correct 786 MB is 47% of *leak suspects* as reported by Eclipse Memory Analyser. Our Cassandra nodes are pretty standard: 10 GB of ram with Xmx set to 2,5 GB. Regards, Romain --=_alternative 002B7D6BC12579DE_= Content-Type: text/html; charset="US-ASCII"
I've just opened a new JIRA: CASSANDRA-4142

I've double checked numbers, 7747 seems to be array list object's capacity (Eclipse Memory Analyzer displays "java.lang.Object[7747] @ 0x7d3f3f798").
Actually there are 5757 browsable entries in EMA therefore each object is about 140 KB (size varies between 143088 bits and 143768 bits).

We have no pending compactions tasks. Our cluster is currently under-loaded.

Our goal is to handle hundreds of tera bytes which explains 1 TB per node. Our need is to archive data so our cluster is not running under a read-heavy load.

@Dave Brosius: I made a mistake. To be correct 786 MB is 47% of *leak suspects* as reported by Eclipse Memory Analyser.
Our Cassandra nodes are pretty standard: 10 GB of ram with Xmx set to 2,5 GB.

Regards,

Romain --=_alternative 002B7D6BC12579DE_=--