Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 2 May 2007 17:28:04 -0400 (EDT)
From:      Rick Macklem <rmacklem@uoguelph.ca>
To:        Robert Watson <rwatson@FreeBSD.org>
Cc:        Craig Boston <craig@xfoil.gank.org>, Pawel Jakub Dawidek <pjd@FreeBSD.org>, freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, Kris Kennaway <kris@obsecurity.org>, Peter Schuller <peter.schuller@infidyne.com>
Subject:   Re: ZFS committed to the FreeBSD base.
Message-ID:  <Pine.GSO.4.63.0705021717500.13892@muncher>
In-Reply-To: <20070502154934.E30345@fledge.watson.org>
References:  <20070407165759.GG8831@cicely12.cicely.de> <20070407180319.GH8831@cicely12.cicely.de> <20070407191517.GN63916@garage.freebsd.pl> <20070407212413.GK8831@cicely12.cicely.de> <20070410003505.GA8189@nowhere> <46365F76.7090708@infidyne.com> <20070430213043.GF67738@garage.freebsd.pl> <463665F2.8090605@infidyne.com> <46373CAD.6000502@infidyne.com> <Pine.GSO.4.63.0705011033410.23282@muncher> <20070501160213.GA496@xor.obsecurity.org> <Pine.GSO.4.63.0705011630010.15295@muncher> <20070502154934.E30345@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help


On Wed, 2 May 2007, Robert Watson wrote:
[stuff snipped] 
>
> Historically, such panics have been a result of one of two things:
>
> (1) An immediate resource leak in UMA(9) or malloc(9) allocated memory.
>
> (2) Mis-tuning of a resource limit, perhaps due to sizing the limit based on
>    solely physical memory size, not taking available kernel address space
>    into account.
>
> mti_stats reports only on malloc(9), you need to also look at uma(9), since 
> many frequently allocated types are allocated directly with the slab 
> allocator, and not from kernel malloc.  Take a look at the output of "show 
> uma" or "show malloc" in DDB, or respectively "vmstat -z" and "vmstat -m" on 
> a core or on a live system.  malloc(9) is actually implemented using two 
> different back-ends: UMA-managed fixed size memory buckets for small 
> allocations, and direct page allocation for large allocations.

Ok, it does appear I'm leaking NAMEIs. "vmstat -z", which I didn't know
about, was the trick. Handling lookup name buffers is also port specific,
so it wouldn't have shown up in the other ports.

So, forget what I said w.r.t. a MALLOC bug and thanks for the help. I
should be able to locate the leak pretty easily with "vmstat -z".

Thanks, rick




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.63.0705021717500.13892>