> But I wonder can this be the problem? (claiming 55% of memory in > kmem_alloc_xxx buffers, which totals at about 16GB! ) Didn't those > "simple" exec (ps, perl, grep, prtdiag etc.) free the buffers/memory > when they exit?
Many of these allocations probably were freed. Remember, this script is just showing you the processes that have allocated the most memory. It's a starting point for drilling into the problem, if one exists. > What is more, as my understanding, the dtrace scripts we run only > monitor those exec calling kmem_alloc at the time while the dtrace > script is running, what about those exec already have kmem_alloc_xx > buffers allocated and in use? Yes, that's correct. However, there's a tradeoff. Kmem_audit will keep the last stack of the thread that alloc'd or free'd the buffer. Unfortuantely, that consumes kernel memory. If you're worried about your kernel memory being used up, using kmem_audit will consume more memory. In my previous e-mail, I suggested kmem_audit as a last resort when tracking down memory problems. Setting kmem_flags requires you to reboot your system, wheras DTrace can be run on a production box at any time. Using DTrace, you can see what threads are allocating and freeing kernel memory, but only for the duration of the trace. Once the trace is complete, the DTrace buffers are freed. It's up to you to decide what approach is most appropriate. -j _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
