From owner-freebsd-stable@FreeBSD.ORG Fri Apr 27 06:31:05 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8BA4E106564A; Fri, 27 Apr 2012 06:31:05 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 30BC38FC12; Fri, 27 Apr 2012 06:31:05 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1SNehi-0006DQ-RY; Fri, 27 Apr 2012 09:30:55 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Hiroki Sato In-reply-to: <20120427.133556.1957776674947898933.hrs@allbsd.org> References: <1527622626.3418715.1335445225510.JavaMail.root@erie.cs.uoguelph.ca> <20120427.133556.1957776674947898933.hrs@allbsd.org> Comments: In-reply-to Hiroki Sato message dated "Fri, 27 Apr 2012 13:35:56 +0900." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Apr 2012 09:30:54 +0300 From: Daniel Braniss Message-ID: Cc: killing@multiplay.co.uk, rmacklem@uoguelph.ca, freebsd-stable@FreeBSD.org, ob@e-Gitt.NET Subject: Re: 9-STABLE, ZFS, NFS, ggatec - suspected memory leak X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 06:31:05 -0000 > ----Security_Multipart(Fri_Apr_27_13_35_56_2012_748)-- > Content-Type: Text/Plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > Rick Macklem wrote > in <1527622626.3418715.1335445225510.JavaMail.root@erie.cs.uoguelph.ca>: > > rm> Steven Hartland wrote: > rm> > ---- Original Message ----- > rm> > From: "Rick Macklem" > rm> > > At a glance, it looks to me like 8.x is affected. Note that the > rm> > > bug only affects the new NFS server (the experimental one for 8.x) > rm> > > when exporting ZFS volumes. (UFS exported volumes don't leak) > rm> > > > rm> > > If you are running a server that might be affected, just: > rm> > > # vmstat -z | fgrep -i namei > rm> > > on the server and see if the 3rd number shown is increasing. > rm> > > rm> > Many thanks Rick wasnt aware we had anything experimental enabled > rm> > but I think that would be a yes looking at these number:- > rm> > > rm> > vmstat -z | fgrep -i namei > rm> > NAMEI: 1024, 0, 1, 1483, 25285086096, 0 > rm> > vmstat -z | fgrep -i namei > rm> > NAMEI: 1024, 0, 0, 1484, 25285945725, 0 > rm> > > rm> ^ > rm> I don't think so, since the 3rd number (USED) is 0 here. > rm> If that # is increasing over time, you have the leak. You are > rm> probably running the old (default in 8.x) NFS server. > > Just a report, I confirmed it affected 8.x servers running newnfs. > > Actually I have been suffered from memory starvation symptom on that > server (24GB RAM) for a long time and watching vmstat -z > periodically. It stopped working once a week. I investigated the > vmstat log again and found the amount of NAMEI leak was 11,543,956 > (about 11GB!) just before the locked-up. After applying the patch, > the leak disappeared. Thank you for fixing it! > > -- Hiroki this is on 8.2-STABLE/amd64 from around August: same here, this zfs+newnfs has been hanging every few months, and I can see now the leak, it's slowly increasing: NAMEI: 1024, 0, 122975, 529, 15417248, 0 NAMEI: 1024, 0, 122984, 520, 15421772, 0 NAMEI: 1024, 0, 123002, 502, 15424743, 0 NAMEI: 1024, 0, 123008, 496, 15425464, 0 cheers, danny