From owner-freebsd-hackers Fri Oct 30 16:19:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA12890 for freebsd-hackers-outgoing; Fri, 30 Oct 1998 16:19:47 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA12885 for ; Fri, 30 Oct 1998 16:19:46 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id QAA02943; Fri, 30 Oct 1998 16:18:57 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199810310018.QAA02943@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: David G Andersen cc: hackers@FreeBSD.ORG, sclawson@cs.utah.edu, mike@fast.cs.utah.edu Subject: Re: nfs/amd hangs / getattr request flood problem In-reply-to: Your message of "Fri, 30 Oct 1998 15:37:02 MST." <199810302237.PAA01262@lal.cs.utah.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Oct 1998 16:18:57 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > We're in the process of configuring some new machines (for personal and > distributed build farm use), and we're seeing some atrocities with amd. > The machines are running 3.0-RELEASE (plus the last few days of checked in > fixes). They receive AMD maps via NIS and a static map, but disabling NIS > doesn't affect things. We've made significant tweaks to the rest of the > system configuration (disabling nis, mfs, slowing things down, etc) and > tried it on multiple systems, and the problem keeps popping up. This > behavior isn't exhibited in 2.2.x. > > We have AMD looking at /n/{machine}/path, with the actual mounts on > /a/{machine}. When compiling with a source tree on /n/machine/path and an > object tree on local /z, AMD can use up to 50% of the processor. Ktrace > and tcpdump output shows that it's handling around 150 getattr requests > per second, on "/n" and "/n/machine", and the ktrace indicates that that's > the _only_ thing it's doing. This may be related to a known defect in the BSD NFS code; we don't cache getattr requests nor do we cache access requests. > There don't seem to be any references to this in gnats or on the lists. > We're working on forward-porting the 2.2.x amd to 3.0 to see if the > behavior still exists, but in the meantime, if anyone has suggestions / > thoughts / knows what's wrong and wants to clue me in, it'd be greatly > appreciated. :) 2.2 has the same problems, although it's amd may not suffer the consequences. You can save yourself a lot of effort by resurrecting the 3.0 AMD from the attic (check out the relevant directories a few days before the new AM-utils stuff went in). -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message