Date: Fri, 30 Aug 2002 12:39:00 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Marc G. Fournier" <scrappy@hub.org> 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: <200208301939.g7UJd0Pb031372@apollo.backplane.com> References: <20020830162006.J14642-100000@mail1.hub.org>
next in thread | previous in thread | raw e-mail | index | archive | help
: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?200208301939.g7UJd0Pb031372>