On Wed, May 02, 2007 at 05:28:04PM -0400, Rick Macklem wrote: > > > 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". I fixed two NAMI zone leaks in the last 2-3 month. One was in the nfs server (shall be present in 6.2-RELEASE, AFAIR), second was in UFS snapshotting code, and is MFCed several days ago.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:09 UTC