Re: kmem_map too small: 3832475648 total allocated

From: Artem Belevich <fbsdlist_at_src.cx>
Date: Thu, 29 Apr 2010 11:25:46 -0700
If I understand it correctly,  the problem in this case is that even
when you do have more than enough RAM, kernel just does not provide
enough space in kmem_map to map that physical memory into.

Unless you want to have dedupe turned on large filesystem (and FreeBSD
does not have this feature yet), you don't really *need* all that much
RAM. "kmem_map too small" comes up as an issue way more often than
lack of physical memory.

--Artem



On Thu, Apr 29, 2010 at 9:56 AM, Scott Long <scottl_at_samsco.org> wrote:
> On Apr 29, 2010, at 9:44 AM, Tom Evans wrote:
>> On Thu, Apr 29, 2010 at 3:53 PM, Ollivier Robert
>> <roberto_at_keltia.freenix.fr> wrote:
>>> According to James R. Van Artsdalen:
>>>> system is a Core i7 975 (3.33 GHz x 4 cores 3x threads per core) with 12
>>>> GB of RAM, a 2x2TB ZFS boot pool and a second (idle) pool of 16x2TB.
>>>
>>>> panic: kmem_malloc(131072): kmem_map too small: 3832475648 total allocated
>>>
>>> Apart from the fact that you must at least set vm.kmem_size to something like 2x your RAM, one rule of thumb I've seen discussed for ZFS is that you will need approximatively 1 GB of RAM per TB of data so you may be a bit short here to get optimal perfs.
>>>
>>
>> Citation needed? I have a file server running amd64 8-STABLE with 4GB
>> of RAM, 6 x 1.5 TB drives in raidz, and have never had any problems
>> with memory usage. Are you saying that after my next update, adding
>> another 6 x 1.5 TB drives, it will start being flaky and/or panicing
>> with kmem_map too small errors?
>>
>
> I'm sorry, but I find it absolutely absurd that any filesystem has to wire down 2GB of RAM, and that the solution to panics is buy more RAM.
>
> Scott
>
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>
Received on Thu Apr 29 2010 - 16:25:55 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:03 UTC