on 24/09/2010 16:37 Leroy van Logchem said the following:
> On Fri, Sep 24, 2010 at 3:04 PM, Andriy Gapon wrote:
>> On amd64 set your vm.kmem_size to at least the amount of available memory
>> that you
>> got, or even more (1.5x, 2x).
>> An easy way to do that (1x) is to set vm.kmem_size_scale="1
On Fri, Sep 24, 2010 at 3:04 PM, Andriy Gapon wrote:
> On amd64 set your vm.kmem_size to at least the amount of available memory
> that you
> got, or even more (1.5x, 2x).
> An easy way to do that (1x) is to set vm.kmem_size_scale="1".
> In head this is already done automatically, MFC to stable/8
on 24/09/2010 15:33 Jeremy Chadwick said the following:
> As for your questions under "Questions" -- yes you have to tune, no
> there aren't really "reliable guidelines" and I've been asking for such
> since ZFS came out for FreeBSD, but your values look fine.
I can't provide you "reliable" or "au
On Fri, Sep 24, 2010 at 03:46:49PM +0300, Andriy Gapon wrote:
> on 24/09/2010 15:33 Jeremy Chadwick said the following:
> > On Fri, Sep 24, 2010 at 01:24:46PM +0200, Leroy van Logchem wrote:
> >> -
> >> Problem : K
on 24/09/2010 15:33 Jeremy Chadwick said the following:
> On Fri, Sep 24, 2010 at 01:24:46PM +0200, Leroy van Logchem wrote:
>> -
>> Problem : Kernel panic "kmem_malloc(114688): kmem_map too small
>> Trigger
On Fri, Sep 24, 2010 at 01:24:46PM +0200, Leroy van Logchem wrote:
> -
> Problem : Kernel panic "kmem_malloc(114688): kmem_map too small
> Trigger : Destroy ZFS snapshots (each bigger >80GB)
> Version
-
Problem : Kernel panic "kmem_malloc(114688): kmem_map too small
Trigger : Destroy ZFS snapshots (each bigger >80GB)
Version : FreeBSD 8.1-RELEASE (GENERIC AMD64 but with DDB)
Workaround :
Am 26.10.2006 um 15:47 schrieb Stefan Bethke:
So far, the machines always just hang instead of dumping core; I'll
see if I can get them to write a dump. Can umastat be run against
a live kernel? Then I could try running it as a cron job to record
data up to just before the panic.
Still
Am 26.10.2006 um 15:47 schrieb Stefan Bethke:
Am 26.10.2006 um 15:37 schrieb Robert Watson:
On Thu, 26 Oct 2006, Stefan Bethke wrote:
acpica 3024 159K 20026966
...
db> show uma
Zone AllocsFrees UsedCache
64
Am 26.10.2006 um 15:37 schrieb Robert Watson:
On Thu, 26 Oct 2006, Stefan Bethke wrote:
acpica 3024 159K 20026966
...
db> show uma
Zone AllocsFrees UsedCache
64 9990754 9986054 4700 9980755
On Thu, 26 Oct 2006, Stefan Bethke wrote:
acpica 3024 159K 20026966
...
db> show uma
Zone AllocsFrees UsedCache
64 9990754 9986054 4700 9980755
Looks like acpica has gone crazy performing a
Am 26.10.2006 um 12:36 schrieb Stefan Bethke:
Am 26.10.2006 um 12:20 schrieb Robert Watson:
After a bit of looking at the output, etc, I agree with your
conclusion that what's there now is lacking. The attached patch,
committed to -CURRENT but not yet to -STABLE, makes the "show
malloc"
Am 26.10.2006 um 09:32 schrieb Stefan Bethke:
Am 26.10.2006 um 02:34 schrieb Scott Long:
There are no obvious culprits from what you posted. [...] Can you
try the following two commands:
vmstat -m
sysctl hw.busdma
Just reset the machine to run these two commands. Will set up a
cron jo
Am 26.10.2006 um 12:20 schrieb Robert Watson:
After a bit of looking at the output, etc, I agree with your
conclusion that what's there now is lacking. The attached patch,
committed to -CURRENT but not yet to -STABLE, makes the "show
malloc" DDB output a bit more like the "vmstat -m" outpu
On Thu, 26 Oct 2006, Robert Watson wrote:
On Wed, 25 Oct 2006, Scott Long wrote:
There are no obvious culprits from what you posted. The kernel was only
trying to allocate 60 bytes, and the 64-byte bucket didn't look to be
overly used. None of the other zones look terribly over-used either
On Wed, 25 Oct 2006, Scott Long wrote:
There are no obvious culprits from what you posted. The kernel was only
trying to allocate 60 bytes, and the 64-byte bucket didn't look to be overly
used. None of the other zones look terribly over-used either. The 'show
malloc' command doesn't really
Am 26.10.2006 um 02:34 schrieb Scott Long:
There are no obvious culprits from what you posted. [...] Can you
try the following two commands:
vmstat -m
sysctl hw.busdma
Just reset the machine to run these two commands. Will set up a cron
job to log them every five minutes so they're avail
Stefan Bethke wrote:
Am 25.10.2006 um 19:36 schrieb Robert Watson:
On Wed, 25 Oct 2006, Stefan Bethke wrote:
We're consistely getting this panic even under smallish loads. I've
experimented with various values for VM_KMEM_SIZE_MAX (384, 512, 768
and 1024 MB), but the boxes are still panic
Am 25.10.2006 um 19:31 schrieb Jeremy Chadwick:
Try tuning memory parameters via loader.conf:
$ cat /boot/loader.conf
# Increase maximum allocatable memory on a process to 768MB.
# We don't choose 2GB (our amount of RAM) since that would
# exhaust all memory, and result in a kernel panic. Maxi
Am 25.10.2006 um 19:36 schrieb Robert Watson:
On Wed, 25 Oct 2006, Stefan Bethke wrote:
We're consistely getting this panic even under smallish loads.
I've experimented with various values for VM_KMEM_SIZE_MAX (384,
512, 768 and 1024 MB), but the boxes are still panicking after
even sh
On Wed, 25 Oct 2006, Stefan Bethke wrote:
We're consistely getting this panic even under smallish loads. I've
experimented with various values for VM_KMEM_SIZE_MAX (384, 512, 768 and
1024 MB), but the boxes are still panicking after even short periods (a few
hours) just doing a buildworld, a
On Wed, Oct 25, 2006 at 07:17:26PM +0200, Stefan Bethke wrote:
> We're consistely getting this panic even under smallish loads. I've
> experimented with various values for VM_KMEM_SIZE_MAX (384, 512, 768
> and 1024 MB), but the boxes are still panicking after even short
> periods (a few hour
We're consistely getting this panic even under smallish loads. I've
experimented with various values for VM_KMEM_SIZE_MAX (384, 512, 768
and 1024 MB), but the boxes are still panicking after even short
periods (a few hours) just doing a buildworld, a few ports compiles,
or even when loggin
On Fri, 6 May 2005, Piotr Gnyp <[EMAIL PROTECTED]> wrote:
panic message:
savecore: reboot after panic: kmem_malloc(45056): kmem
_map too small: 334680064 total allocated
Ok, I`ve found:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html#KMEM-MAP-TOO-SMALL
when i try to do kgdb i get thi
uname -v
FreeBSD 5.3-RELEASE-p9
panic message:
savecore: reboot after panic: kmem_malloc(45056): kmem
_map too small: 334680064 total allocated
when i try to do kgdb i get this:
kgdb: cannot read PTD
Panic after 31 days of uptime.
I will gladly show more data if needed.
--
"How fortunate the man wi
25 matches
Mail list logo
