On Monday 02 March 2009 16:21:53 Andrew Moran wrote: > > What's even weirder is that the process gets that far. Did you play > > with > > kern.maxdsiz loader tuneable? > > If so, set it lower, so you can at least have the machine in a > > usable state at > > all times. 4G should be enough for any process and should give > > enough time > > for you to spot the leak and get a ktrace. > > Nope, I haven't tweaked any kernel settings, just using the generic > DEFAULT amd64 kernel. I've been way about tweaking settings because > I don't fully understand what the 'correct' values for my setup are.
Could you show kenv kern.maxdsiz and if unset limits -H -d? Looks like it's 32G on my 6.x amd64, in which case setting it is a good idea. echo 'kern.maxdsiz="8G"' >> /boot/loader.conf echo 'kern.defdsiz="4G"' >> /boot/loader.conf would set it to 4G soft limit, 8G hard limit. The difference between soft and hard is, that the limits(1) program can be used to run a process with more then 4G allocatable memory and nothing can run with more then 8G, until loader tunable is changed and a reboot is done. I really have no idea why on amd64 this default is so high, surely 32G for a process is an extreme circumstance, for which one would require 4 physical CPU's to begin with. -- Mel Problem with today's modular software: they start with the modules and never get to the software part. _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"