# [OmniOS-discuss] ILB memory leak?

Ryan Zezeski ryan at zinascii.com
Thu Oct 22 15:13:05 UTC 2015

- Previous message: [OmniOS-discuss] ILB memory leak?
- Next message: [OmniOS-discuss] ILB memory leak?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    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

- Previous message: [OmniOS-discuss] ILB memory leak?
- Next message: [OmniOS-discuss] ILB memory leak?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the OmniOS-discuss mailing list