Date: Mon, 10 May 2010 09:03:37 -0700 From: Artem Belevich <fbsdlist@src.cx> To: Mike Andrews <mandrews@bit0.com> Cc: freebsd-stable@freebsd.org Subject: Re: Freebsd 8.0 kmem map too small Message-ID: <m2ved91d4a81005100903vc4e6d6c3ud3ab0cac3ba6c729@mail.gmail.com> In-Reply-To: <4BE82C5D.1080806@bit0.com> References: <4BDEA86E.3050109@zirakzigil.org> <20100503110100.GA93137@icarus.home.lan> <4BDEC106.3040807@zirakzigil.org> <4BE110E3.8040902@zirakzigil.org> <q2vb269bc571005050819nde819098vfd3306170639a9c9@mail.gmail.com> <4BE82C5D.1080806@bit0.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On this specific system, it has 32 GB physical memory and has > vfs.zfs.arc_max=3D"2G" and vm.kmem_size=3D"64G" in /boot/loader.conf. =A0= 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=3D63G would work much better. --Artem On Mon, May 10, 2010 at 8:55 AM, Mike Andrews <mandrews@bit0.com> wrote: > On 5/5/10 11:19 AM, Freddie Cash wrote: >> >> On Tue, May 4, 2010 at 11:32 PM, Giulio Ferro<auryn@zirakzigil.org> >> =A0wrote: >> >>> 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... =A0I'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 allocate= d > panic: kmem_malloc(131072): kmem_map too small: 2011525120 total allocate= d > panic: kmem_malloc(114688): kmem_map too small: 1849356288 total allocate= d > panic: kmem_malloc(114688): kmem_map too small: 1849356288 total allocate= d > panic: kmem_malloc(114688): kmem_map too small: 1849356288 total allocate= d > panic: kmem_malloc(131072): kmem_map too small: 2020409344 total allocate= d > panic: kmem_malloc(536576): kmem_map too small: 2022957056 total allocate= d > > (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=3D"2G" and vm.kmem_size=3D"64G" in /boot/loader.conf. =A0= 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 potentiall= y > offending commit was on. =A0It happened at least twice overnight, where > several memory-intensive jobs run. =A0Backing 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. =A0I do= have > KDB/DDB and serial console on this box, if there's any more info I can gi= ve > 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 A= tom > one... > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m2ved91d4a81005100903vc4e6d6c3ud3ab0cac3ba6c729>