Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 29870 invoked from network); 5 Aug 2010 18:52:30 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 5 Aug 2010 18:52:30 -0000 Received: (qmail 9381 invoked by uid 500); 5 Aug 2010 18:52:28 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 9344 invoked by uid 500); 5 Aug 2010 18:52:28 -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 9336 invoked by uid 99); 5 Aug 2010 18:52:28 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Aug 2010 18:52:28 +0000 X-ASF-Spam-Status: No, hits=0.7 required=10.0 tests=RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.212.44] (HELO mail-vw0-f44.google.com) (209.85.212.44) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Aug 2010 18:52:19 +0000 Received: by vws10 with SMTP id 10so5743404vws.31 for ; Thu, 05 Aug 2010 11:51:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.122.24 with SMTP id j24mr7654397vcr.14.1281034316926; Thu, 05 Aug 2010 11:51:56 -0700 (PDT) Sender: scode@scode.org Received: by 10.220.202.71 with HTTP; Thu, 5 Aug 2010 11:51:56 -0700 (PDT) X-Originating-IP: [213.114.155.57] In-Reply-To: References: Date: Thu, 5 Aug 2010 20:51:56 +0200 X-Google-Sender-Auth: 66sVecN5VkRk8amlFiuBd3OFSIE Message-ID: Subject: Re: Cassandra disk space utilization WAY higher than I would expect From: Peter Schuller To: user@cassandra.apache.org Content-Type: text/plain; charset=UTF-8 X-Virus-Checked: Checked by ClamAV on apache.org Oh and, > Nodetool cleanup works so beautifully, that I am wondering if there is any harm > in using "nodetool cleanup" in a cron job on a live system that is actively > processing reads and writes to the database? since a cleanup/compact is supposed to trigger a full compaction, that's generating a lot of I/O that is normally deferred. Doing it nightly won't scale in the general case (suppose you have terrabytes of data...). But assuming compaction does not have a sufficiently detrimental effect on your application and your data size is small enough that a compaction finishes within some reasonable amount of time, I don't see a problem with it. That said, since cleanup by design actually permanently removes data not belonging to nodes, it might be dangerous in the event that there is somehow confusion over what data nodes are responsible for. A regular compaction should not, as far as I know, ever remove data not belonging to the node. So I can certainly see a danger there; personally I'd probably want to avoid automating 'cleanup' for that reason. But; if everything works reasonably it still seems to me that you should not be seeing extreme wastes of diskspace. If you truly need to compact nightly to save space, you might be running too close to your maximum disk capacity anyway. That said if you're still seeing extreme amounts of "extra" disk space I don't think there is yet an explanation for that in this thread. Also, the variation in disk space in your most recent post looks entirely as expected to me and nothing really extreme. The temporary disk space occupied during the compact/cleanup would easily be as high as your original disk space usage to begin with, and the fact that you're reaching the 5-7 GB per node level after a cleanup has completed fully and all obsolete sstables have been removed, does not necessarily help you since each future cleanup/compaction will typically double your diskspace anyway (even if temporarily). -- / Peter Schuller