REVIEW: https://review.gluster.org/18915 (core: glusterd is consuming high memory during volume provisioning) posted (#1) for review on master by MOHIT AGRAWAL
Bug summary: User experienced high resource usage when testing brick multiplexing with a large number of volumes. This in the end lead to issues with bricks not starting, and inconsistent states. Possibly being caused due to some inefficiencies in graph load code.
COMMIT: https://review.gluster.org/18915 committed in master by \"MOHIT AGRAWAL\" <moagrawa> with a commit message- glusterd : Fix glusterd mem leaks Problem: glusterd eats a huge amount of meory during volume set/stop/start. Solution: At the time of compare graph topology create a graph and populate key values in the dictionary, after finished graph comparison we do destroy the new graph.At the time of construct graph we don't take any reference and for server xlators we do take reference in server_setvolume so in glusterd we do take reference after prepare a new graph while we do create a graph to compare graph topology. BUG: 1520245 Change-Id: I573133d57771b7dc431a04422c5001a06b7dda9a Signed-off-by: Mohit Agrawal <moagrawa>
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-4.0.0, please open a new bug report. glusterfs-4.0.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] http://lists.gluster.org/pipermail/announce/2018-March/000092.html [2] https://www.gluster.org/pipermail/gluster-users/