Red Hat Bugzilla – Bug 848341
glusterfs process is taking some 70% mem usage after some stress testing.
Last modified: 2013-09-23 18:36:19 EDT
+++ This bug was initially created as a clone of Bug #809063 +++
Created attachment 574469 [details]
glusterfs process statedump.
Description of problem:
statedump output -
--- Additional comment from firstname.lastname@example.org on 2012-04-11 07:20:19 EDT ---
mostly looks like some fragmentation looking at uord_blks and ord_blks
--- Additional comment from email@example.com on 2012-04-19 03:39:39 EDT ---
Next time you run these set of tests, please run it through Valgrind, so we can capture the leaks well.
One of the possibility is quick-read's dictionary getting cached in md-cache, which can lead to a huge leak (Thanks to Brian Foster/Avati on the md-cache/quick-read causing memory consumption)
--- Additional comment from firstname.lastname@example.org on 2012-04-19 03:42:24 EDT ---
> One of the possibility is quick-read's dictionary getting cached in md-cache,
> which can lead to a huge leak (Thanks to Brian Foster/Avati on the
> md-cache/quick-read causing memory consumption)
Thanks to Brian Foster and Avati on *finding* the memory consumption issue when md-cache and quick-read are used together.
--- Additional comment from email@example.com on 2012-05-04 03:01:42 EDT ---
Taking this out of Beta Blocker considering multiple patches which have gone into fix the obvious memory leaks. Only seriously pending tasks would be to handle md-cache/quick-read memory consumption behavior, for which Brian Foster already sent a patch.
This bug is not seen in current master branch (which will get branched as RHS 2.1.0 soon). To consider it for fixing, want to make sure this bug still exists in RHS servers. If not reproduced, would like to close this.
After a couple of day's of stress testing including:
* multiple kernel compiles.
* large directory tree copying
* metadata intensive workloads
* rsync huge directory trees
* rename tests in a loop
I'm not able to hit the issue, will continue tests for couple of more days before I mark this as fixed.
After multiple stress tests, the memory consumption doesn't up drastically, stays down to a few megs.
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.