From owner-freebsd-fs Fri Jul 14 15:24: 1 2000 Delivered-To: freebsd-fs@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id 2D3ED37BF60 for ; Fri, 14 Jul 2000 15:23:53 -0700 (PDT) (envelope-from mbendiks@eunet.no) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id AAA35674; Sat, 15 Jul 2000 00:23:50 +0200 (CEST) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id AAA21048; Sat, 15 Jul 2000 00:23:50 +0200 (CEST) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Sat, 15 Jul 2000 00:23:50 +0200 (CEST) From: Marius Bendiksen To: Duane Wessels Cc: freebsd-fs@FreeBSD.ORG Subject: [kern/19479] Re: vnode/inode starvation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As noone seems to have touched the PR, you might want to try the following patch: --- ffs_vfsops.c.orig Sat Jul 15 00:24:10 2000 +++ ffs_vfsops.c Sat Jul 15 00:24:43 2000 @@ -1038,9 +1038,9 @@ /* Allocate a new vnode/inode. */ error = getnewvnode(VT_UFS, mp, ffs_vnodeop_p, &vp); if (error) { if (ffs_inode_hash_lock < 0) - wakeup(&ffs_inode_hash_lock); + wakeup_one(&ffs_inode_hash_lock); ffs_inode_hash_lock = 0; *vpp = NULL; FREE(ip, ump->um_malloctype); return (error); @@ -1067,9 +1067,9 @@ */ ufs_ihashins(ip); if (ffs_inode_hash_lock < 0) - wakeup(&ffs_inode_hash_lock); + wakeup_one(&ffs_inode_hash_lock); ffs_inode_hash_lock = 0; /* Read in the disk contents for the inode, copy into the inode. */ error = bread(ump->um_devvp, fsbtodb(fs, ino_to_fsba(fs, ino)), --eof-- It's also available from my homepage at http://home.eunet.no/~mbendiks/patches/ffs-fix2.patch --- Marius Bendiksen On Mon, 26 Jun 2000, Duane Wessels wrote: > Hi, > > I have an application -- a caching proxy called Squid. When benchmarking > Squid on FreeBSD-3.5, I'm seeing very high vnode (inode?) usage. After running > for a few hours under peak load, all of the kernel virtual memory (?) > is consumed by vnodes: > > Memory statistics by type Type Kern > Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) > 256 file desc, devbuf, temp, subproc, vnodes, ifaddr, routetbl, FFS node > FFS node343147 85787K 85787K 85787K 742322 1 0 256 > > At this point, any process that wants a new vnode is blocked. Top > shows many processes in 'ffsvgt' state, and one process in 'FFS no' > state. > > I'm using the RELENG_3 branch, sucked down on June 20: > FreeBSD mr-garrison.measurement-factory.com 3.5-STABLE FreeBSD 3.5-STABLE #4: Tue Jun 20 14:15:04 MDT 2000 > root@mr-garrison.measurement-factory.com:/usr/src/sys/compile/SQUID i386 > > > I don't know a whole lot about kernel code and these sorts of low-level > filesystem details. But it seems to me this is really strange. I don't > unerstand why vnodes aren't being reused or freed. > > Does vnode reclaimation sort of rely on processes not living very > long? In my case I have six squid processes that never die, each of > which can touch 500,000 or more disk files. > > Ideas, references, explanations welcome... > > Duane W. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-fs" in the body of the message > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message