From owner-freebsd-hackers Fri Jul 23 17:33: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id 4F40C14F89 for ; Fri, 23 Jul 1999 17:32:56 -0700 (PDT) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (monica.cs.rpi.edu [128.213.7.2]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id UAA02766; Fri, 23 Jul 1999 20:32:07 -0400 (EDT) Message-Id: <199907240032.UAA02766@cs.rpi.edu> To: Matthew Dillon Cc: "David E. Cross" , David Malone , Doug , freebsd-hackers@FreeBSD.ORG, crossd@cs.rpi.edu Subject: Re: mbuf leakage in NFSv3 writes, possbile? In-Reply-To: Message from Matthew Dillon of "Fri, 23 Jul 1999 17:14:55 PDT." <199907240014.RAA30153@apollo.backplane.com> Date: Fri, 23 Jul 1999 20:32:07 -0400 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well, backing out now is not really an option... But given my past history with NFS, and knowledge of this site I think I have a fair idea where the leak is... I think it is in the nfsv3 "commit" handler. Why do I think this? Simple, this problem started when a user started running a large job on out origin 2k, prior to that our server had been up for 30-ish days sans any problems, since his start it requires a boot-a-day (mbuf clusters are up to 8k). Also supporting this is the fact that the clusters are used at a fairly constant rate. Now (following that hunch), I did a tcpdump against that host for tcp traffic, and noticed a fairly steady stream of "commit" NFS traffic. I realize none of this is a smoking gun, but that is where my "hunch" lies. How is mbuf cluster cleanyup done? If I knew I might have a shot in heck at locating this problem. BTW: updated netstat -m for the machine: 4855/5344 mbufs in use: 4848 mbufs allocated to data 7 mbufs allocated to packet headers 4774/4850/8704 mbuf clusters in use (current/peak/max) 10368 Kbytes allocated to network (97% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines That's alot of buffer ;) -- David Cross | email: crossd@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message