Return-Path: X-Original-To: apmail-zookeeper-user-archive@www.apache.org Delivered-To: apmail-zookeeper-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 4358FF54D for ; Mon, 8 Apr 2013 16:40:37 +0000 (UTC) Received: (qmail 64903 invoked by uid 500); 8 Apr 2013 16:40:35 -0000 Delivered-To: apmail-zookeeper-user-archive@zookeeper.apache.org Received: (qmail 64871 invoked by uid 500); 8 Apr 2013 16:40:35 -0000 Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@zookeeper.apache.org Delivered-To: mailing list user@zookeeper.apache.org Received: (qmail 64863 invoked by uid 99); 8 Apr 2013 16:40:35 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 Apr 2013 16:40:35 +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 (athena.apache.org: domain of mathias.hodler@gmail.com designates 209.85.215.181 as permitted sender) Received: from [209.85.215.181] (HELO mail-ea0-f181.google.com) (209.85.215.181) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 Apr 2013 16:40:30 +0000 Received: by mail-ea0-f181.google.com with SMTP id z10so2455519ead.40 for ; Mon, 08 Apr 2013 09:40:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=rSu8L1IASNi+wZl/ZTmvyI9QEb9va20bQkq5rbp5F+8=; b=Jwc4xtIuUsRg7QyNWQrSNZcTvjl/BUlLLiRLyfMcysrq0VOe8CGz1KfW7CHuUc65qE cvKkYWeGZQf+EPyfCYyvQDpiXAuYY2P1ezBC9sxW1MFAAK9xBVXILFudIojcrTc6UGP7 YyIY+aeAQqaD0xJyxR7kHuJgO8GhygZGPcw9zdDmdheP6zJTIXH1Dg4XE9ECWX6bSQmY xeMqR+k7ndzauJQsjc7PNb+EofPP00jkV+zrYXvRl54DiS8YSuCxCr99zrZW8uVf+v15 zdzV7HEPqFbKSfamAtbwFMIxSNbPACRXxCUYd6dnwZ6xtFciZIuytr7GKe+M99VPyx49 Bpzg== MIME-Version: 1.0 X-Received: by 10.14.107.69 with SMTP id n45mr28764874eeg.23.1365439209079; Mon, 08 Apr 2013 09:40:09 -0700 (PDT) Received: by 10.14.144.10 with HTTP; Mon, 8 Apr 2013 09:40:08 -0700 (PDT) In-Reply-To: References: Date: Mon, 8 Apr 2013 18:40:08 +0200 Message-ID: Subject: Re: Zookeeper does not clean up deleted nodes From: Mathias Hodler To: user@zookeeper.apache.org Content-Type: multipart/alternative; boundary=001a11c2899e052aa104d9dc1791 X-Virus-Checked: Checked by ClamAV on apache.org --001a11c2899e052aa104d9dc1791 Content-Type: text/plain; charset=ISO-8859-1 Thanks, this could be the reason. I only used a single zookeeper server, so it should act as a leader. So if I need to store larger files (about 1MB) the only option is to increase the heap space? I know that zookeeper is designed for small files, but I'm using zookeeper with solr and solr stores all the index configuration with large dictionaries in zookeeper. 2013/4/8 Benjamin Reed > are you looking at the leader or the follower? the leader keeps the last > few transactions in memory to speed up syncing with new followers. that > might be what you are seeing. > > > On Mon, Apr 8, 2013 at 3:32 AM, Mathias Hodler >wrote: > > > Hi, > > > > I made some tests and it seems like zookeeper doesn't clean up the last > 500 > > deleted nodes. > > > > In my test I created nodes and deleted each node after it was created. I > > repeated this step 1000 times and then triggered a full gc. These are the > > results > > > > Creating 1000 Nodes and deleting 1000 Nodes and each node has... > > ...1000kb data = 529MB heap used after FullGC > > ...500kb data = 281MB heap used after FullGC > > ...256kb data = 140MB heap used after FullGC > > ...128kb data = 68MB heap used after FullGC > > > > If I'm creating 1000 nodes with each 1000kb data and then deleting the > > nodes and after that creating 1000 nodes with 128kb data and deleting the > > nodes again, 68MB heap space is used. > > > > So it seems Zookeeper caches / doesn't clean up the last 500 deleted > nodes. > > > > Is this a bug or are there configuration parameter to change that > > behaviour? > > > --001a11c2899e052aa104d9dc1791--