[Gluster-devel] Script to identify ref leaks

Sonal Arora sarora at redhat.com
Tue Apr 4 13:01:19 UTC 2017


Hi,

I need four vm's(one with  16gb RAM, rest : 8gb, Disk storage : 30 gb.) to
test the ref-leak script. Are there any spare instances floating around ?

Regards
-Sonal

On Sat, Apr 1, 2017 at 1:08 AM, Sonal Arora <sarora at redhat.com> wrote:

>
>
> On Mar 31, 2017 7:05 PM, "Niels de Vos" <ndevos at redhat.com> wrote:
>
> On Fri, Mar 31, 2017 at 01:24:41PM +0000, Atin Mukherjee wrote:
> > On Fri, 31 Mar 2017 at 18:15, Niels de Vos <ndevos at redhat.com> wrote:
> >
> > > On Fri, Mar 31, 2017 at 02:34:04PM +0530, Sanoj Unnikrishnan wrote:
> > > > +Mohit
> > > > Mohit had written a similar script to RCA an issue couple of months
> back.
> > > >
> > > > It would help if we placed the scripts, tapsets in the source tree
> itself
> > > > (maybe in a directory under glusterfs/extras/).
> > > > We could also have the tapset packaged into debuginfo packages and
> > > deployed
> > > > under /usr/share/systemtap/ path upon installation.
> > >
> > > Yes, or we can place them in their own repository. I have a
> > > gluster-debug repository where I plan to put tools I use for debugging.
> > > This repository may well live at the Gluster organization on GitHub
> too.
> > >
> > > https://github.com/nixpanic/gluster-debug
> > >
> > > Many of the tools we use for debugging should not be version specific,
> > > so having them in the glusterfs repository might be a little awkward?
> > >
> > > What are the opinions of others?
> >
> >
> > My personal preference would be to host it under one central repo instead
> > of individual github accounts. Versioning and such other issues can be
> > tackled having good documentation around these tools.
>
> Yes, of course. I intended to explain we put all the debug tools in
> https://github.com/gluster/gluster-debug (does not exist yet). Those
> tools can then also include debug utilities for related projects, not
> only for the core glusterfs repository.
>
> Niels
>
> >
> >
> > >
> > > Thanks,
> > > Niels
> > >
> > >
> > > > Regards,
> > > > Sanoj
> > > >
> > > > On Fri, Mar 31, 2017 at 12:44 PM, Sonal Arora <sarora at redhat.com>
> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I am working on finding ways to indentify ref leaks in glusterfs.
> > > > >
> > > > > Description of Issue :
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1417539
> > > > >
> > > > > Goal : To make script which could detect all kind of ref leaks.
> > > > >
> > > > > Script : https://github.com/SonaArora/Tracing-userspace-app/blob/
> > > > > master/ref-leak/try8-modified
> > > > > The above script is a POC program to depict the idea of how to
> identify
> > > > > leaks. Script is probing dict_ref() and dict_unref() and keeping a
> > > track of
> > > > > the pointers, back traces which are referenced/dereferenced by
> above
> > > > > functions. If the count of refs is unequal to unrefs for each
> > > pointer,it
> > > > > will print all the traces corresponding to the leaked pointer.
> > > > > Output : https://github.com/SonaArora/Tracing-userspace-
> > > > > app/blob/master/ref-leak/output-refleak
> > > > > I am working on post processing the output - to filter only the
> leaked
> > > > > traces and to write the output after every few hours into a file.
> > > > > The script can be extended to all objects being referenced (like
> > > > > inodes/fds).
> > > > >
> > > > > End Goal : Future goal is to make it more versatile, dynamic and
> light
> > > > > weight so that it can be even utilized on production environments
> > > without
> > > > > utilizing much of the system resources.
> > > > >
> > > > > Request your comments and suggestions.
> > > > >
> > > > > Best
> > > > > -Sonal
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Gluster-devel mailing list
> > > > > Gluster-devel at gluster.org
> > > > > http://lists.gluster.org/mailman/listinfo/gluster-devel
> > > > >
> > > _______________________________________________
> > > Gluster-devel mailing list
> > > Gluster-devel at gluster.org
> > > http://lists.gluster.org/mailman/listinfo/gluster-devel
> >
> > --
> > - Atin (atinm)
>
>
>
> That's a good idea to put all such kind of work in one place so that
> everyone can utilize this.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20170404/b03cf2f8/attachment.html>


More information about the Gluster-devel mailing list