From owner-freebsd-stable Fri Aug 30 21:46:51 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E00437B400; Fri, 30 Aug 2002 21:46:47 -0700 (PDT) Received: from earth.hub.org (earth.hub.org [64.49.215.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id D956843E4A; Fri, 30 Aug 2002 21:46:46 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from earth.hub.org (earth.hub.org [64.49.215.11]) by earth.hub.org (Postfix) with ESMTP id 781882CC7F0; Sat, 31 Aug 2002 01:46:38 -0300 (ADT) Date: Sat, 31 Aug 2002 01:46:38 -0300 (ADT) From: "Marc G. Fournier" To: Matthew Dillon Cc: Arnvid Karstad , , Subject: Re: Problems with FreeBSD - causing zalloc to return 0 ?! In-Reply-To: <200208301939.g7UJd0Pb031372@apollo.backplane.com> Message-ID: <20020831014427.X14642-100000@mail1.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Okay, I've setup this script on both my (un)STABLE servers, and will report after the next crash ... which shouldn't take long :) On Fri, 30 Aug 2002, Matthew Dillon wrote: > > :Is there any definite way of determining this? From what I can find int > :he man page, VNODES have to do with the file system and directory lists > :... my last two crashes look to be related to the file system itself, so > :have started to watch the VNODE numbers to, but is there some way of > :determining what I should raise, and where? > > If you can get to a DDB> prompt on the crash (kernel config w/ DDB) > do this: > > ddb> print *kernel_vm_end > > And tell me what you get. Also note the fault address. > > In order to really track down the cause I need a vmcore and kernel.debug > to play with, but baring that you might be able to dump memory > statistics to a file like once a second until the machine crashes. > > while (1) > sleep 1 > date >> stats.log > vmstat -m >> stats.log > vmstat -z >> stats.log > netstat -m >> stats.log > fsync stats.log > end > > :I'm running 4Gig of RAM and Dual CPU over here, so having a swap device > :large enough to 'dump core' is kinda out of the question, so I can't > :provide any more infomration that i have so far in other messages :( > > If you can reproduce the crash with less memory you may be able to > generate a core. To boot the machine with less memory add a line > to your /boot/loader.conf file: > > hw.physmem="768m" > > I usually always keep such a line in my loader.conf file, commented > out (e.g. #hw.physmem=...) until I need it, because I always forget > the name of the variable :-) > > :And, also, should any 'server class' operating system be more graceful > :about such things? Some sort of soft limit that triggers it to refuse new > :processes or something when its hit, so that it doesn't actually crash? > :Kinda like the NMBCLUSTERS warning/error message when its set too low? > > FreeBSD-current will be far more graceful, but FreeBSD-stable is still > using algorithms based on circa 1990 system memory capacities. As > memory capacities have grown larger then available KVM the algorithms > have been less able to cope with the massive number of resources > that can now be cached. > > -Matt > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message