> On this specific system, it has 32 GB physical memory and has > vfs.zfs.arc_max="2G" and vm.kmem_size="64G" in /boot/loader.conf. The > latter was added per earlier suggestions on this list, but appears to be > ignored as "sysctl vm.kmem_size" returns about 2 GB (2172452864) anyway.
Set vm.kmem_size to slightly below 2x the amount of physical memory your kernel *sees* (sysctl hw.physmem) . Chances are that real amount of physical memory available to kernel is slightly below 32G so your tunable is ignored. My guess would be that vm.kmem_size=63G would work much better. --Artem On Mon, May 10, 2010 at 8:55 AM, Mike Andrews <mandr...@bit0.com> wrote: > On 5/5/10 11:19 AM, Freddie Cash wrote: >> >> On Tue, May 4, 2010 at 11:32 PM, Giulio Ferro<au...@zirakzigil.org> >> wrote: >> >>> Giulio Ferro wrote: >>> >>>> Thanks, I'll try these settings. >>>> >>>> I'll keep you posted. >>>> >>> >>> Nope, it's happened again... Now I've tried to rise vm.kmem_size to 6G... >>> I'm really astounded at how unstable zfs is, it's causing me a lot of >>> problem. >>> Why isn't it stated in the handbook that zfs isn't up to production yet? >>> >> >> As with everything related to computers, it all depends on your uses. > > Sorry to semi-hijack this, but... I'm also running into frequent "kmem_map > too small" panics on 8-STABLE, such as: > > panic: kmem_malloc(131072): kmem_map too small: 2023780352 total allocated > panic: kmem_malloc(131072): kmem_map too small: 2011525120 total allocated > panic: kmem_malloc(114688): kmem_map too small: 1849356288 total allocated > panic: kmem_malloc(114688): kmem_map too small: 1849356288 total allocated > panic: kmem_malloc(114688): kmem_map too small: 1849356288 total allocated > panic: kmem_malloc(131072): kmem_map too small: 2020409344 total allocated > panic: kmem_malloc(536576): kmem_map too small: 2022957056 total allocated > > (those are over the course of 3-4 days) > > On this specific system, it has 32 GB physical memory and has > vfs.zfs.arc_max="2G" and vm.kmem_size="64G" in /boot/loader.conf. The > latter was added per earlier suggestions on this list, but appears to be > ignored as "sysctl vm.kmem_size" returns about 2 GB (2172452864) anyway. > > Unfortunately I have not yet found a way to reliably reproduce the panic on > demand, so it's hard to iteratively narrow down which date the potentially > offending commit was on. It happened at least twice overnight, where > several memory-intensive jobs run. Backing out to a previous 8-STABLE > kernel from March 28 appears (so far) to have stabilized things, so the > offending code was likely somewhere between then and May 5 or so. I do have > KDB/DDB and serial console on this box, if there's any more info I can give > to help troubleshoot other than just a one-month vague date range :) > > This is happening to more than just one system, but I figure it's easier to > troubleshoot memory settings on the 32 GB i7 server instead of the 2 GB Atom > one... > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
