Date: Sat, 31 Aug 2002 01:46:38 -0300 (ADT) From: "Marc G. Fournier" <scrappy@hub.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Arnvid Karstad <arnvid@karstad.org>, <bmah@FreeBSD.ORG>, <freebsd-stable@FreeBSD.ORG> Subject: Re: Problems with FreeBSD - causing zalloc to return 0 ?! Message-ID: <20020831014427.X14642-100000@mail1.hub.org> In-Reply-To: <200208301939.g7UJd0Pb031372@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020831014427.X14642-100000>