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 [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Reply via email to