[Bugs] [Bug 1558379] Huge memory usage of FUSE client

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1558379



--- Comment #5 from Pranith Kumar K <pkarampu at redhat.com> ---
(In reply to Yannick Perret from comment #3)
> So, more tests.
> 
> I performed 16 loops of extracting the same archive onto the same place
> (overwriting content) in a FUSE mountpoint with patched 3.13.2 client.
> The volume is a x2 replica (default configuration) from 2 servers with the
> same OS (fresh Debian 8 64b) and the same glusterfs version (but not patched
> on servers).
> 
> Without the patch after *each* FS operation the memory size of the client
> process grows. With the patch it grows until a certain point and then stay
> stable. The archive is the latest linux kernel tarball (~154M).
> 
> Here is the client process VSZ/RSS over time:
> 
> 427796 10788 (initial memory, just after mounting)
> 427796 10788
> 493332 21020 (starting extracting archive)
> 493332 27772
> 493332 45620
> 493332 63072
> (…)
> 493332 88904
> 493332 104484
> 493332 128672
> (…)
> 689940 223832
> 689940 228404
> At this point memory size is stable.
> 
> Later I started an other extraction of the same archive in an other target
> directory, while the main loop was still running. Memory increase again a
> little:
> 689940 232172
> (…)
> 757612 363916
> 757612 373788
> 757612 383672
> 757612 394316
> 757612 404792
> (…)
> 888684 455848
> At this point memory size is again stable.
> 
> 
> So clearly the memory leak related to every operations is corrected, at
> least for my configuration / options (note: without the patch even listing
> content increased the memory size).
> 
> 
> In my point of view there is still a question: why the memory never reduce?
> Now all operations are over on the mountpoint (for ~4 hours now) and memory
> size is still exactly the same.
> I also then deleted all content from the mountpoint without any change.
> 
> Is it an other kind of memory leak? Is it some kind of cached data? But if
> it is cached data it should have expired now, moreover after deleting all
> content (caching non-existing nodes don't seems useful).
> 
> 
> I can of course perform more tests if it can help, please let me know.
> By my side I will run other copies with other directory targets, in order to
> see if memory will still grows (a little now) and stay like this.
> 
> Thanks,
> --
> Y.

What you can give me is the statedump of the client before running the test and
statedump of the client after running these tests and deleting all the content
you created as part of the test.
With these two files, I can compare what grew to see if it is expected or
something more needs to be fixed.

kill -USR1 <pid-of-client-process> generates statedump at "/var/run/gluster"
with the pattern glusterdump.<pid>.<timestamp>
Upload these two files and we will have some data to analyse.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.