-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10-5-2010 20:09, Bruce Cran wrote:
> On Friday 30 April 2010 09:11:49 Gary Jennejohn wrote:
>
>> A number of variables go into calculating vm.kmem_size (see kmeminit()
>> in kern_malloc.c).
>>
>> In the end, the kernel won't allocate more than twic
On Friday 30 April 2010 09:11:49 Gary Jennejohn wrote:
> A number of variables go into calculating vm.kmem_size (see kmeminit()
> in kern_malloc.c).
>
> In the end, the kernel won't allocate more than twice the physical memory
> size _which it has discovered_.
>
> The question is, how much of yo
On Fri, 30 Apr 2010 00:27:00 +0200
Willem Jan Withagen wrote:
> On 29-4-2010 6:17, Artem Belevich wrote:
> > Do you have vm.kmem_size set in /boot/loader.conf?
> >
> > If not, do set it to about double of your physical RAM size. Defaults
> > are way too conservative for use with large amounts of
On 29-4-2010 6:17, Artem Belevich wrote:
Do you have vm.kmem_size set in /boot/loader.conf?
If not, do set it to about double of your physical RAM size. Defaults
are way too conservative for use with large amounts of memory and ZFS.
As per this suggestion I set this value to 2*8G:
vm.kmem_size
According to Tom Evans:
> 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 p
Scott Long wrote:
>
> 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
The only thing buying more RAM is likely to do is make the memory leak
behind this harder to reproduce. Likewise increasing kernel tunab
Андрей Смагин wrote:
> > panic: kmem_malloc(131072): kmem_map too small: 3832475648 total allocated
> >
> I open PR amd64/145654 with problem like it. Have you increasing Wired memory
> at buildworld ?
>
No. This
# while true
> do
> sysctl -A | grep wired
> make -j8 buildworld
> done
is g
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)
On Apr 29, 2010, at 9:44 AM, Tom Evans wrote:
> On Thu, Apr 29, 2010 at 3:53 PM, Ollivier Robert
> 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.
>>
On Thu, Apr 29, 2010 at 3:53 PM, Ollivier Robert
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: 38
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
Do you have vm.kmem_size set in /boot/loader.conf?
If not, do set it to about double of your physical RAM size. Defaults
are way too conservative for use with large amounts of memory and ZFS.
--Artem
On Wed, Apr 28, 2010 at 8:07 PM, James R. Van Artsdalen
wrote:
> FreeBSD bigback.housenet.jrv
12 matches
Mail list logo
