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 237086972 for ; Wed, 1 Jun 2011 06:08:02 +0000 (UTC) Received: (qmail 55841 invoked by uid 500); 1 Jun 2011 06:08:01 -0000 Delivered-To: apmail-zookeeper-user-archive@zookeeper.apache.org Received: (qmail 55792 invoked by uid 500); 1 Jun 2011 06:08:01 -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 55782 invoked by uid 99); 1 Jun 2011 06:08:00 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Jun 2011 06:08:00 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of ted.dunning@gmail.com designates 209.85.220.170 as permitted sender) Received: from [209.85.220.170] (HELO mail-vx0-f170.google.com) (209.85.220.170) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Jun 2011 06:07:54 +0000 Received: by vxb40 with SMTP id 40so5216364vxb.15 for ; Tue, 31 May 2011 23:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=rcZDpW3RF9ewq/9nojOjMOqwviEmv97RGIcybrgt0go=; b=Y4G/8RphodxKO8VzW5uk/6mcqgvO9OiF4QKrCFtI91IxyBNVHyEoSTXt7XZDuLwnND tHIx4VsiB4rtNnX9QrHdNUjal8BHoI0UtvpXsJ1RoF9Iz2OK9WxG7bquQseu8VHHJOrA 915HKcoOAIjVuJXVwVodlh+JLwjob74LMd2A4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=pad+uibWEekyfSrLVHqAk6ORb/m30HgoegOB26/itGXRBzt1BzHQdZAEtBC9/XV8Ue +EAdv+58G48PWesek6aTNlG66wjSCbKSOrwE3JjsjvSXyeur6l8lq1TNe6DQxznoCln2 1jBuxw+y8jEV0cuVut1KXr7OP1DS98XAQ1rCo= Received: by 10.52.76.193 with SMTP id m1mr4130541vdw.204.1306908453063; Tue, 31 May 2011 23:07:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.110.101 with HTTP; Tue, 31 May 2011 23:07:13 -0700 (PDT) In-Reply-To: <574546.7700.qm@web113310.mail.gq1.yahoo.com> References: <574546.7700.qm@web113310.mail.gq1.yahoo.com> From: Ted Dunning Date: Tue, 31 May 2011 23:07:13 -0700 Message-ID: Subject: Re: Memory leak in zookeeper 3.3.2 and 3.3.3? To: user@zookeeper.apache.org Content-Type: multipart/alternative; boundary=bcaec501603b194a9504a4a0562d --bcaec501603b194a9504a4a0562d Content-Type: text/plain; charset=UTF-8 What happens if you stop the client (either an orderly shutdown, closing ZK or a hard stop with enough time for ephemerals to go away)? Does GC then reclaim the memory? What does the dump command show in terms of how many connections and ephemerals there are? What does ls in the command line client show for how many znodes there are? Usually when I see this sort of behavior means that I have been accumulating data in ZK in a way that I didn't intend. I have had ZK up for months to years without seeing this behavior. On Tue, May 31, 2011 at 11:00 PM, Victor wrote: > Hi, > I apologize for the broadcasting. I searched the archive before I send > this email to the mailing list. > > We are using Cages library + Zookeeper 3.3.3 to synchronize creation of > forum user name (which needs to be unique). > This is the only use case that we write in ZooKeeper. > > We used Cages ZkWriteLock to obtain write lock and below is the code > (which is very straightforward): > org.wyki.zookeeper.cages.ZkWriteLock lock = new > org.wyki.zookeeper.cages.ZkWriteLock("/User/ForumUsername/" + > forumUsername); > try { > boolean lockAcquired = lock.acquire(5, TimeUnit.SECONDS); > ...... > } finally { > lock.release(); > } > > In our load test (1 single Zookeeper server), even with 3GB max heap > size, ZooKeeper runs out of memory after ~3 hours. > So I decided to profile Zookeeper with YourKit Jave profile (9.5) against > one Zookeeper server. After every 6 above calls to ZooKeeper (I randomly > picked 6), I saw the memory usage increased ~200K (in Yourkit retained size > increased ~220K and shallow size increased > Even after 1 hour or more, even if I forced garbage collection (done in > YourKit), the memory increased due to the 6 calls didn't get released. I ran > the 6 calls for a few times and observed the same. So I suspect there is a > memory leak (and that is why we got OutOfMemory in load test) > Looking further at the hotspot using Yourkit, the memory increase are in > the form of String, char[], Class, HashMap$Entry (java classes or types) and > maily from below method invocation: > > org.apache.zookeeper.server.FinalRequestProcessor.processRequest(Request) > org.apache.zookeeper.server.PrepRequestProcessor.pRequest(Request) > org.apache.zookeeper.server.NIOServerCnxn$Factory.run() > > But from the code, leakage is not obvious. > > > We used below JVM (for ZooKeeper) startup options/flags: > -server -Xms1536m -Xmx3072m -Xloggc:/var/zookeeper/logs/gc.log > -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime > -XX:+PrintGC -XX:+PrintGCTimeStamps -XX:+PrintGCDetails > -XX:ParallelGCThreads=8 -XX:+UseConcMarkSweepGC > -Dcom.sun.management.jmxremote > -Dcom.sun.management.jmxremote.authenticate=false > -Dcom.sun.management.jmxremote.ssl=false > -Dcom.sun.management.jmxremote.port=54321 -Dcom.sun.management.jmxremote > -Dcom.sun.management.jmxremote.local.only=false > > I looked at ZooKeeper documentation thoroughly (especially the > administration guide), but couldn't find a way to tune this (to avoid above > suspected memory leak) > > Is there a memory leak in Zookeeper 3.3.3 (or 3.3.2)? If there is, How > could we configure ZooKeeper to avoid/reduce that leak? What is the > stable version to use? did we misconfigure anything? > > Please advise or help. Thanks a lot! > > Victor --bcaec501603b194a9504a4a0562d--