-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
Thu, 29 Apr 2010 16:20:32 -0500 письмо от "James R. Van Artsdalen"
:
> Андрей Смагин wrote:
> > > panic: kmem_malloc(131072): kmem_map too small: 3832475648 total
> > allocated
> > >
> > I open PR amd64/145654 with problem like it. Have you
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
>
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.
>>>
>>>> pani
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
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(131
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 yo
> The panic happened during the 27th iteration.
>
> 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 ?
___
freebsd-curre
pool and a second (idle) pool of 16x2TB.
>
> The system was running this in the clang build area:
>
> while true
> do
> make -j7 buildworld
> done
>
> The panic happened during the 27th iteration.
>
> panic: kmem_mallo
and a second (idle) pool of 16x2TB.
The system was running this in the clang build area:
while true
do
make -j7 buildworld
done
The panic happened during the 27th iteration.
panic: kmem_malloc(131072): kmem_map too small: 3832475648 total allocated
15 matches
Mail list logo
