Date: Tue, 05 Feb 2002 08:30:00 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Sergey Gershtein <sg@ur.ru> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: FS gurus needed! (was: Strange lock-ups during backup over nfs after adding 1024M RAM) Message-ID: <20020205083000.I72285@gsmx07.alcatel.com.au> In-Reply-To: <114283707399.20020204172833@ur.ru>; from sg@ur.ru on Mon, Feb 04, 2002 at 05:28:33PM %2B0500 References: <20020126204941.H17540-100000@resnet.uoregon.edu> <1931130530386.20020128130947@ur.ru> <20020130073449.B78919@gsmx07.alcatel.com.au> <791310002584.20020130150111@ur.ru> <20020131111153.Y72285@gsmx07.alcatel.com.au> <1427021336.20020201123650@ur.ru> <20020204130730.B72285@gsmx07.alcatel.com.au> <114283707399.20020204172833@ur.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2002-Feb-04 17:28:33 +0500, Sergey Gershtein <sg@ur.ru> wrote: >On Monday, February 04, 2002 Peter Jeremy <peter.jeremy@alcatel.com.au> wrote: >PJ> One oddity here is the Size - "FFS node" is used to allocate struct >PJ> inode's and they should be 256 bytes on i386. Are you using something >PJ> other than an i386 architecture? Unless this is a cut-and-paste >PJ> error, I suspect something is radically wrong with your kernel. > >Yes, it's i386 and it's not cut-and-paste error. Looking at your dmesg, you're running RELENG_4_4 - I has incorrectly assumed you were running RELENG_4. The size of struct inode has changed (it shrank by 4 bytes), meaning it's now 256 bytes instead of 260 bytes (which requires 512 bytes from the allocator). That explains that discrepancy. This is corrected in src/sys/ufs/ufs/inode.h,v 1.28.2.2. I think RELENG_4_4 also explains your problem: There was a problem that vnodes were being cached too long and there was effectively no upper limit on their number. I gather that under some conditions (which I don't recall, but you seem to have hit) the vnode cache (and underlying inode cache) would eat all the KVM. There were a variety of commits by Matt Dillon between October and early November that fixed this. Have a search through the archives for references to "kern.maxvnodes". I'd suggest that you look at moving to RELENG_4_5 or RELENG_4. This will halve the size of FFS node entries (which is most of your kernel memory) and allow you to limit it to something saner. >Hmm. Not sure what to do. Shell I try to play with kern.vm.kmem.size >or better not touch it? I'm not sure why there is a 200MB cap. Since your machine isn't short of physical memory (no swapping), I don't see any problem with increasing it to something like 500MB (which would be its uncapped value). Try adding "kern.vm.kmem.size=524288000" to /boot/loader.conf > I am now thinking that removing the extra >memory we've added is the best solution to the problem. I don't like >this solution though. I don't understand why you don't have the problem on the smaller box. >I don't expect the number of open files go beyond 1,000-1,500. The >only problem is accessing a lot (more than a 1,000,000) of small files >over NFS. But if I understand correctly, those files should be opened >and closed one by one, not all together. Is that right? The problem seems to be the vnode cache - which isn't being cleaned correctly. >PJ> Does "vfscache" have around the same number of InUse entries as "FFS node"? > >Yes, it seems so (see above). What does it mean? Most (all?) "FFS node" entries should be pointed to by vfscache (vnode) entries. If this isn't so, then there's a bug releasing inodes. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020205083000.I72285>