Re: Freebsd 8.0 kmem map too small

> 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 <[e-mail]> wrote:
> On 5/5/10 11:19 AM, Freddie Cash wrote:
>>
>> On Tue, May 4, 2010 at 11:32 PM, Giulio Ferro<[e-mail]>
>> =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...
> _______________________________________________
> [e-mail] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[e-mail]"
>
_______________________________________________
[e-mail] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[e-mail]"