[Bugs] [Bug 1372729] New: Possible VSZ leak in glusterfsd brick process

bugzilla at redhat.com bugzilla at redhat.com
Fri Sep 2 13:48:39 UTC 2016


            Bug ID: 1372729
           Summary: Possible VSZ leak in glusterfsd brick process
           Product: GlusterFS
           Version: 3.7.15
         Component: core
          Severity: medium
          Assignee: bugs at gluster.org
          Reporter: oleksandr at natalenko.name
                CC: bugs at gluster.org

Description of problem:

Given replica 2 serving mainly one big distributed-replicated 5 × 2 volume
(backups with lots of operations with small files):

Volume Name: backups
Type: Distributed-Replicate
Status: Started
Number of Bricks: 5 x 2 = 10
Transport-type: tcp
Brick1: pussy.example.com:/mnt/backups_1/backups
Brick2: heimdall.example.com:/mnt/backups_1/backups
Brick3: pussy.example.com:/mnt/backups_2/backups
Brick4: heimdall.example.com:/mnt/backups_2/backups
Brick5: pussy.example.com:/mnt/backups_3/backups
Brick6: heimdall.example.com:/mnt/backups_3/backups
Brick7: pussy.example.com:/mnt/backups_4/backups
Brick8: heimdall.example.com:/mnt/backups_4/backups
Brick9: pussy.example.com:/mnt/backups_5/backups
Brick10: heimdall.example.com:/mnt/backups_5/backups
Options Reconfigured:
cluster.entry-self-heal: off
cluster.metadata-self-heal: off
cluster.data-self-heal: off
performance.readdir-ahead: on
nfs.disable: on

Over the last month we observe constant VSZ usage of bricks processes. After
updating to 3.7.15 it seems the issue is still there (please see graphs

Version-Release number of selected component (if applicable):

3.7.14, 3.7.15.

How reproducible:


Steps to Reproduce:
1. create distributed-replicated 5 × 2 volume;
2. perform lots of operations with small files (like git commit on GlusterFS
volume — we backup /etc of many servers to it);
3. ...

Actual results:

VSZ grows slowly.

Expected results:

VSZ should not grow to that values.

Additional info:

Graphs attached represent sum of VSZ values over all glusterfsd processes
within one node.

RSS also grows, starting from ~80M at the beginning to ~300M before node
upgrade. It is considerably larger value than is observed for volumes without
such a workload with millions of files.

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

More information about the Bugs mailing list