[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
https://bugzilla.redhat.com/show_bug.cgi?id=1372729
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
Bricks:
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
attached).
Version-Release number of selected component (if applicable):
3.7.14, 3.7.15.
How reproducible:
Always.
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. ...
4. PROFIT.
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