Red Hat Bugzilla – Bug 1552360
memory leak in pre-op in replicate volumes for every write
Last modified: 2018-09-18 02:52:11 EDT
+++ This bug was initially created as a clone of Bug #1550078 +++ Description of problem: When glusterfs is git cloned on the volume, we see lot of dict leaks root@dhcp35-190 - ~ 18:48:02 :) ⚡ grep -w num_allocs /var/run/gluster/glusterdump.3513.dump.1519822531 | cut -f2 -d'=' | sort -n | tail -10 334 334 442 442 18656 18656 18656 18656 18656 18656 After fix, for the same workload: root@dhcp35-190 - ~ 18:48:07 :) ⚡ grep -w num_allocs /var/run/gluster/glusterdump.12424.dump.1519823735 | cut -f2 -d'=' | sort -n | tail -10 26 29 54 89 324 324 334 334 442 442 This is a regression we missed in: https://review.gluster.org/#/q/ba149bac92d169ae2256dbc75202dc9e5d06538e Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: --- Additional comment from Worker Ant on 2018-02-28 08:24:39 EST --- REVIEW: https://review.gluster.org/19647 (cluster/afr: Fix dict-leak in pre-op) posted (#1) for review on master by Pranith Kumar Karampuri
Update: ========= 1) create 1 * 3 replicate volume and start 2) git clone the glusterfs on the volume ( mount point ) 3) take the dump from client and check the number of num_allocs 4) remove the cloned glusterfs 5) Again git clone the glusterfs on the volume 6) take the dump from client and check the number of num_allocs 7) remove the cloned glusterfs 8) Again git clone the glusterfs on the volume 9) take the dump from client and check the number of num_allocs Observations: Didn't see much increase in num_allocs for every iteration # grep -w num_allocs glusterdump.9167.dump.1532676241_after_1st_clone | cut -f2 -d'=' | sort -n | tail -10 2651 2651 2651 2651 2657 2657 2667 2667 7954 7954 # grep -w num_allocs glusterdump.9167.dump.1532683881_after_2nd_clone | cut -f2 -d'=' | sort -n | tail -10 2651 2651 2651 2651 2836 2836 2846 2846 7954 7954 # grep -w num_allocs glusterdump.9167.dump.1532684833_after_3rd_clone | cut -f2 -d'=' | sort -n | tail -10 2651 2651 2651 2651 2890 2890 2900 2900 7954 7954 #
Details in above comment. Changing status to Verified.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:2607