[OmniOS-discuss] ILB memory leak?

[Ryan Zezeski]

Al Slater writes:

> On 21/10/2015 17:35, Dan McDonald wrote:
>>
>> That should enable user-level memory debugging.  If you get a
>> coredump, save it and share it.  If you don't and the ilb daemon
>> keeps running, eventually please:
>>
>> gcore `pgrep ilbd`
>>
>> and share THAT corefile.  You can also do this by youself:
>>
>> mdb <ilbd-core> > ::findleaks
>>
>> and share ::findleaks.
>>
>> Once you're done generating corefiles, repeat the steps above, but
>> use "unsetenv LD_PRELOAD" and "unsetenv UMEM_DEBUG" instead of the
>> setenv lines.
>
> Thanks Dan.  As we are talking about production boxes here, I will have 
> to try and reproduce on another box and then I will give the process 
> above a go and see what we come up with.

You can also use the DTrace pid provider to grab the user stack on every
malloc(3C) call, and the syscall provider to track mmap(2) calls. That
poses no harm to production and might make the cause of memory usage
obvious.

Something like:

dtrace -qn 'pid$target::malloc:entry { @[ustack()] = count(); }
syscall::mmap*:entry /pid == $target/ { @[ustack()] = count(); }' -p <PID>

Let that run for a while as the memory grows, then Ctrl-C.

-Z