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 BC6EB177F5 for ; Thu, 16 Oct 2014 13:41:43 +0000 (UTC) Received: (qmail 17352 invoked by uid 500); 16 Oct 2014 13:41:41 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 17312 invoked by uid 500); 16 Oct 2014 13:41:40 -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 17302 invoked by uid 99); 16 Oct 2014 13:41:40 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Oct 2014 13:41:40 +0000 X-ASF-Spam-Status: No, hits=2.4 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of asf11@outlook.com designates 65.54.190.166 as permitted sender) Received: from [65.54.190.166] (HELO BAY004-OMC3S28.hotmail.com) (65.54.190.166) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Oct 2014 13:41:14 +0000 Received: from BAY169-W13 ([65.54.190.187]) by BAY004-OMC3S28.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 16 Oct 2014 06:41:12 -0700 X-TMN: [29tIxQHcuaplFTrtwl4yCDh4n7cxTEr7] X-Originating-Email: [asf11@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_7ed7d5bf-6546-4df9-8642-526b655182cf_" From: S C To: "user@cassandra.apache.org" Subject: RE: validation compaction Date: Thu, 16 Oct 2014 08:41:12 -0500 Importance: Normal In-Reply-To: References: ,, MIME-Version: 1.0 X-OriginalArrivalTime: 16 Oct 2014 13:41:12.0339 (UTC) FILETIME=[D9850630:01CFE946] X-Virus-Checked: Checked by ClamAV on apache.org --_7ed7d5bf-6546-4df9-8642-526b655182cf_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bob=2C Default compression is Snappy compression and I have seen compression rangi= ng between 2-4% (just as the doc says). I got the storage part. Does it mea= n that as a result of compaction/repair SSTables are decompressed? Is it th= e reason for CPU utilization spiking up a little? -SR From: asf11@outlook.com To: user@cassandra.apache.org Subject: RE: validation compaction Date: Tue=2C 14 Oct 2014 17:09:14 -0500 =0A= =0A= =0A= Thanks Rob.=20 Date: Mon=2C 13 Oct 2014 13:42:39 -0700 Subject: Re: validation compaction From: rcoli@eventbrite.com To: user@cassandra.apache.org On Mon=2C Oct 13=2C 2014 at 1:04 PM=2C S C wrote: =0A= =0A= =0A= I have started repairing a 10 node cluster with one of the table having > 1= TB of data. I notice that the validation compaction actually shows >3 TB in= the "nodetool compactionstats" bytes total. However=2C I have less than 1T= B data on the machine. If I take into consideration of 3 replicas then 3TB = makes sense. Per my understanding=2C validation does only care about data l= ocal to the machine running validation compaction. Am I missing some thing = here? Any help is much appreciated.=20 Compression is enabled by default=3B it's showing the uncompressed data siz= e. Your 1TB of data would be 3TB without compression. =3DRob = --_7ed7d5bf-6546-4df9-8642-526b655182cf_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Bob=2C

Defaul= t compression is Snappy compression and I have seen compression ranging bet= ween 2-4% (just as the doc says). I got the storage part. Does it mean that= as a result of compaction/repair SSTables are decompressed? Is it the reas= on for CPU utilization spiking up a little?

-SR

From: asf11@outlook.com
To: user@cassandra= .apache.org
Subject: RE: validation compaction
Date: Tue=2C 14 Oct 20= 14 17:09:14 -0500

=0A= =0A= =0A=
Thanks Rob. =3B



Date: Mon=2C 13 Oct 2014 13:42:39 -0700
Subject: Re: validation com= paction
From: rcoli@eventbrite.com
To: user@cassandra.apache.org
<= br>
On Mon=2C Oct 13=2C 2014 at 1:04 PM=2C S C <=3Basf11@outlook.com&g= t=3B wrote:
=0A= =0A= =0A=
I have started repairing a 10 node cluster with one o= f the table having >=3B 1TB of data. I notice that the validation compact= ion actually shows >=3B3 TB in the "nodetool compactionstats" bytes total= . However=2C I have less than 1TB data on the machine. If I take into consi= deration of 3 replicas then 3TB makes sense. Per my understanding=2C valida= tion does only care about data local to the machine running validation comp= action. Am I missing some thing here? Any help is much appreciated. =3B=

Compression is enabled by = default=3B it's showing the uncompressed data size. Your 1TB of data would = be 3TB without compression.

=3DRob
 = =3B
=
= --_7ed7d5bf-6546-4df9-8642-526b655182cf_--