Date: Mon, 10 May 2010 11:55:09 -0400 From: Mike Andrews <mandrews@bit0.com> To: freebsd-stable@freebsd.org Subject: Re: Freebsd 8.0 kmem map too small Message-ID: <4BE82C5D.1080806@bit0.com> In-Reply-To: <q2vb269bc571005050819nde819098vfd3306170639a9c9@mail.gmail.com> References: <4BDEA86E.3050109@zirakzigil.org> <20100503110100.GA93137@icarus.home.lan> <4BDEC106.3040807@zirakzigil.org> <4BE110E3.8040902@zirakzigil.org> <q2vb269bc571005050819nde819098vfd3306170639a9c9@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5/5/10 11:19 AM, Freddie Cash wrote: > On Tue, May 4, 2010 at 11:32 PM, Giulio Ferro<auryn@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...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BE82C5D.1080806>