[Bugs] [Bug 1751014] New: Memory leak when often run gluster volume status

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1751014

            Bug ID: 1751014
           Summary: Memory leak when often run gluster volume status
           Product: GlusterFS
           Version: 6
          Hardware: x86_64
                OS: Linux
            Status: NEW
         Component: glusterd
          Assignee: bugs at gluster.org
          Reporter: padner2002 at list.ru
                CC: bugs at gluster.org
  Target Milestone: ---
    Classification: Community



Description of problem:
A few days after installing new three node cluster with glusterfs 4.1.8,
process glusterd on the one node was killed by OOM. We restarted it and saw
high memory consumption by glusterd process on other two nodes. Then we updated
the version: 4.1.8 -> 4.1.9 -> 5.9 -> 6.5. But after update the situation has
not changed. After comparing this setup with another, it turned out that the
difference in monitoring. Monitoring run 'gluster volume status' command every
minute on each node in this new cluster. After disable monitoring of first
node, we saw, that glusterd RSS memory growth slowed down on other(2,3) nodes.
And if stop monitoring of second node, RSS growth has stopped only on third,
but on 1,2 slowed down. If disable monitoring on all nodes, RSS growth has
stopped on all nodes.

Version-Release number of selected component (if applicable):
glusterfs-libs-6.5-1.el7.x86_64
glusterfs-api-6.5-1.el7.x86_64
glusterfs-6.5-1.el7.x86_64
glusterfs-fuse-6.5-1.el7.x86_64
glusterfs-cli-6.5-1.el7.x86_64
glusterfs-client-xlators-6.5-1.el7.x86_64
glusterfs-server-6.5-1.el7.x86_64


How reproducible:


Steps to Reproduce:
1. Setup 3 node cluster with 1 repcate volume
2. Run 'gluster volume status' every minute on one node
3. See how glusterd memory consumption is growing on other 2 nodes

Actual results:


Expected results:
no increase in memory consumption of glusterd process

Additional info:

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.