From owner-freebsd-bugs Sat Sep 22 14:26:35 2001 Delivered-To: freebsd-bugs@freebsd.org Received: from root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 3C35B37B419; Sat, 22 Sep 2001 14:26:31 -0700 (PDT) Received: (from dg@localhost) by root.com (8.11.2/8.11.2) id f8ML7Gd29928; Sat, 22 Sep 2001 14:07:16 -0700 (PDT) (envelope-from dg) Date: Sat, 22 Sep 2001 14:07:16 -0700 From: David Greenman To: Mike Barcroft Cc: freebsd-bugs@FreeBSD.org Subject: Re: kern/19479: processes stuck in 'ffsvgt' and 'FFS no' states Message-ID: <20010922140716.B28469@nexus.root.com> References: <200109220310.f8M3A2570482@freefall.freebsd.org> <20010922135045.A28469@nexus.root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010922135045.A28469@nexus.root.com>; from dg@root.com on Sat, Sep 22, 2001 at 01:50:45PM -0700 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >> FFS node204489102245K 102245K102400K 663650 0 0 512 >> >> >> 102245K seems like an awful lot of memory for FFS nodes? >> what would cause this? does anyone else see very large FFS node >... >> clearly we are reaching the malloc limit for "FFS node" and hanging. > > Yes, and it is easy to reproduce. Just read/write a lot of files (a few >hundred thousand) on a machine with a lot of memory (1GB or more). The >problem is caused by FreeBSD's overly agressive desire to keep vnodes (and >their attached FS nodes) around in order to be able to cache the associated >file data. I haven't looked at the problem in great detail (I would have a >fix for this if I had), but basically there needs to be a cap on how many >vnodes are allowed to stick around after all the references have been dropped >and vnodes with no cached pages should be freed immediately. There used to >be such a cap, but someone removed it a long time ago. Looks like there is another contributor to this, as pointed out by Matt Dillon, the namei cache is part of the problem as well. The algorithm tries to hang on to the vnode so that the namei cache entries don't become useless (they point to vnodes, so if the vnode is recycled then the namei cache entry becomes useless). All of this code is tricky with complex relationships and interactions. It's not going to be trivial to come up with a good fix that doesn't also sacrifice performance one way or another. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message