Bug 1467986
| Summary: | possible memory leak in glusterfsd with multiplexing | ||
|---|---|---|---|
| Product: | [Community] GlusterFS | Reporter: | Mohammed Rafi KC <rkavunga> |
| Component: | core | Assignee: | Mohammed Rafi KC <rkavunga> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | mainline | CC: | amukherj, bugs, jdarcy, jeff, kramdoss, nchilaka, pasik, rcyriac, shberry |
| Target Milestone: | --- | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Fixed In Version: | glusterfs-3.12.0 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 1426291 | Environment: | |
| Last Closed: | 2017-09-05 17:35:44 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1426291 | ||
| Bug Blocks: | 1457936 | ||
|
Description
Mohammed Rafi KC
2017-07-05 17:48:57 UTC
REVIEW: https://review.gluster.org/17709 (mgtm/core : implement sha hash function for volfile check) posted (#1) for review on master by mohammed rafi kc (rkavunga) REVIEW: https://review.gluster.org/17709 (mgtm/core : implement sha hash function for volfile check) posted (#2) for review on master by mohammed rafi kc (rkavunga) REVIEW: https://review.gluster.org/17709 (mgtm/core : implement sha hash function for volfile check) posted (#3) for review on master by mohammed rafi kc (rkavunga) REVIEW: https://review.gluster.org/17709 (mgtm/core : implement sha hash function for volfile check) posted (#4) for review on master by mohammed rafi kc (rkavunga) REVIEW: https://review.gluster.org/17709 (glusterfs/mgmt : implement sha hash function for volfile check) posted (#5) for review on master by mohammed rafi kc (rkavunga) REVIEW: https://review.gluster.org/17709 (mgtm/core : implement sha hash function for volfile check) posted (#6) for review on master by mohammed rafi kc (rkavunga) REVIEW: https://review.gluster.org/17709 (mgtm/core : implement sha hash function for volfile check) posted (#7) for review on master by mohammed rafi kc (rkavunga) REVIEW: https://review.gluster.org/17709 (mgtm/core : use sha hash function for volfile check) posted (#8) for review on master by mohammed rafi kc (rkavunga) REVIEW: https://review.gluster.org/17709 (mgtm/core : use sha hash function for volfile check) posted (#9) for review on master by mohammed rafi kc (rkavunga) REVIEW: https://review.gluster.org/17709 (mgtm/core : use sha hash function for volfile check) posted (#10) for review on master by mohammed rafi kc (rkavunga) REVIEW: https://review.gluster.org/17709 (mgtm/core : use sha hash function for volfile check) posted (#11) for review on master by mohammed rafi kc (rkavunga) COMMIT: https://review.gluster.org/17709 committed in master by Pranith Kumar Karampuri (pkarampu) ------ commit f2f3d74c835b68ad9ec63ec112870829a823a1fb Author: Mohammed Rafi KC <rkavunga> Date: Thu Jul 6 13:26:42 2017 +0530 mgtm/core : use sha hash function for volfile check We are storing the entire volfile and using this to check volfile change. With brick multiplexing there will be lot of graphs per process which will increase the memory foot print of the process. So instead of storing the entire graph we could use sha256 and we can compare the hash to see whether volfile change happened or not. Also with Brick multiplexing, the direct comparison of vol file is not correct. There are two problems. Problem 1: We are currently storing one single graph (the last updated volfile) whereas, what we need is the entire graph with all atttached bricks. If we fix this issue, we have second problem Problem 2: With multiplexing we have a graph that contains multiple bricks. But what we are checking as part of the reconfigure is, comparing the entire graph with one single graph, which will always fail. Solution: We create list in glusterfs_ctx_t that stores sha256 hash of individual brick graphs. When a graph changes happens we compare the stored hash and the current hash. If the hash matches, then no need for reconfigure. Otherwise we first do the reconfigure and then update the hash. For now, gfapi has not changed this way. Meaning when gfapi volfile fetch or reconfigure happens, we still store the entire graph and compare, each memory. This is fine, because libgfapi will not load brick graphs. But changing the libgfapi will make the code similar in both glusterfsd-mgmt and api. Also it helps to reduce some memory. Change-Id: I9df917a771a52b95622ab8f63af34ec390163a77 BUG: 1467986 Signed-off-by: Mohammed Rafi KC <rkavunga> Reviewed-on: https://review.gluster.org/17709 Smoke: Gluster Build System <jenkins.org> Reviewed-by: Pranith Kumar Karampuri <pkarampu> CentOS-regression: Gluster Build System <jenkins.org> Reviewed-by: Atin Mukherjee <amukherj> Reviewed-by: Amar Tumballi <amarts> 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-3.12.0, please open a new bug report. glusterfs-3.12.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/2017-September/000082.html [2] https://www.gluster.org/pipermail/gluster-users/ |