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 3D09117329 for ; Fri, 20 Mar 2015 16:54:04 +0000 (UTC) Received: (qmail 2151 invoked by uid 500); 20 Mar 2015 16:54:00 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 2110 invoked by uid 500); 20 Mar 2015 16:54:00 -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 2100 invoked by uid 99); 20 Mar 2015 16:54:00 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Mar 2015 16:54:00 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of ben@instaclustr.com designates 209.85.192.177 as permitted sender) Received: from [209.85.192.177] (HELO mail-pd0-f177.google.com) (209.85.192.177) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Mar 2015 16:53:35 +0000 Received: by pdbni2 with SMTP id ni2so113711001pdb.1 for ; Fri, 20 Mar 2015 09:52:02 -0700 (PDT) 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:date :message-id:subject:from:to:content-type; bh=ZUnz6X+SUUjArF2X4hemRsGqno4NUMBkqtvB6DSywTg=; b=HilmLgJPYeUAtPGUMLg7NAWZVf385IVdE5lTdQuyRy9eLJWdhcaJpqdvrPiVXAUjTn aPGINxs9fF5DxpEpb54uBsL58dIfSdWXzD15Mfcz/NYVYFK8AxIifadurYNzbxG/aqUP 04da9/7N8EabSt1FwPoEuqo+KpLba2VWyGSrFH7Hbrko0LLnBNurGRHCQKDeuIOfuxlO Lj0cDkfEft+APBaAqTri0/Ag/h556Q7bpWlqKkiNTbmiBnkwWYtXh99Kl7kyC+7PzJlm DQowsqlqUqCfPZZhglSRxH2dkxaHmynU86I0swGV4/mbxKWQ8uzU958nPr1nZAAwzhVE LT0g== X-Gm-Message-State: ALoCoQn62jh5V71/t2MZnjXvPa7HQxo0mdhj/uqce+sjM33RillMMRF/KqG4X41TeKpAWMu4v/O+ MIME-Version: 1.0 X-Received: by 10.66.66.75 with SMTP id d11mr187809323pat.132.1426870322225; Fri, 20 Mar 2015 09:52:02 -0700 (PDT) Received: by 10.70.59.105 with HTTP; Fri, 20 Mar 2015 09:52:02 -0700 (PDT) In-Reply-To: References: <54792650.219886.1426544924926.JavaMail.yahoo@mail.yahoo.com> Date: Fri, 20 Mar 2015 09:52:02 -0700 Message-ID: Subject: Re: Deleted snapshot files filling up /var/lib/cassandra From: Ben Bromhead To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=001a11362a8ab290f90511bb229c X-Virus-Checked: Checked by ClamAV on apache.org --001a11362a8ab290f90511bb229c Content-Type: text/plain; charset=UTF-8 Sorry for the late reply. To immediately solve the problem you can restart Cassandra and all the open file descriptors to the deleted snapshots should disappear. As for why it happened I would first address the disk space issue and see if the snapshot errors + open file descriptors issue still occurs (I am unclear as to whether you got the snapshot exception after the disk filled up or before), if you still have issues with repair not letting go of snapshotted files even with free disk space I would look to raise a ticket in Jira. On 17 March 2015 at 12:46, David Wahler wrote: > On Mon, Mar 16, 2015 at 6:51 PM, Ben Bromhead wrote: > > If you are running a sequential repair (or have previously run a > sequential > > repair that is still running) Cassandra will still have the file > descriptors > > open for files in the snapshot it is using for the repair operation. > > Yeah, that aligns with my understanding of how the repair process > works. But the cluster has no repair sessions active (I think; when I > run "nodetool tpstats", the AntiEntropyStage and AntiEntropySessions > values are zero on all nodes) and the space still hasn't been freed. > -- Ben Bromhead Instaclustr | www.instaclustr.com | @instaclustr | (650) 284 9692 --001a11362a8ab290f90511bb229c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry for the late reply.=C2=A0

<= div>To immediately solve the problem you can restart Cassandra and all the = open file descriptors to the deleted snapshots should disappear.=C2=A0

As for why it happened I would first address the disk = space issue and see if the snapshot errors + open file descriptors issue st= ill occurs (I am unclear as to whether you got the snapshot exception after= the disk filled up or before), if you still have issues with repair not le= tting go of snapshotted files even with free disk space I would look to rai= se a ticket in Jira.

On 17 March 2015 at 12:46, David Wahler = <dwahler@indeed.= com> wrote:
On Mon, Mar 16, 2015 at 6:51 PM, Ben Bromhead <ben@instaclustr.com> wrote:
> If you are running a sequential repair (or have previously run a seque= ntial
> repair that is still running) Cassandra will still have the file descr= iptors
> open for files in the snapshot it is using for the repair operation.
Yeah, that aligns with my understanding of how the repair process works. But the cluster has no repair sessions active (I think; when I
run "nodetool tpstats", the AntiEntropyStage and AntiEntropySessi= ons
values are zero on all nodes) and the space still hasn't been freed.



--

Ben Bromhead

Instaclustr |=C2=A0www.instaclustr.com=C2=A0|=C2=A0@instaclustr=C2= =A0| (650) 284 9692

--001a11362a8ab290f90511bb229c--