<html dir="ltr"><head></head><body style="text-align:left; direction:ltr;"><div>Hmm. I just had to jump through lots of issues with a gluster 3.12.9 setup under Ovirt. The mounts are stock fuse.glusterfs. The RAM usage had been climbing and I had to move VMs around, put hosts in maintenance mode, do updates, restart. When the VMs were moved back the memory usage dropped back to normal. The new gluster is 3.12.11 and still using fuse in a replica 3 config. I'm blaming the fuse mount process for the leak (with no data to back it up yet).</div><div><br></div><div>A different gluster install also using fuse mounts does not show the memory consumption. It does not use virtualization at all so it really is likely an issue with the kvm/qemu. On those system, the fuse mounts get dropped by oomkiller when computation use of memory overload things. Different issue totally. </div><div><br></div><div>On Wed, 2018-08-01 at 19:57 +0100, lemonnierk@ulrar.net wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>Hey,</pre><pre><br></pre><pre>Is there by any chance a known bug about a memory leak for the libgfapi</pre><pre>in the latests 3.12 releases ?</pre><pre>I've migrated a lot of virtual machines from an old proxmox cluster to a</pre><pre>new one, with a newer gluster (3.12.10) and ever since the virtual</pre><pre>machines have been eating more and more RAM all the time, without ever</pre><pre>stopping. I have 8 Gb machines occupying 40 Gb or ram, which they</pre><pre>weren't doing on the old cluster.</pre><pre><br></pre><pre>It could be a proxmox problem, maybe a leak in their qemu, but since</pre><pre>no one seems to be reporting that problem I wonder if maybe the newer</pre><pre>gluster might have a leak, I believe libgfapi isn't used much.</pre><pre>I tried looking at the bug tracker but I don't see anything obvious, the</pre><pre>only leak I found seems to be for distributed volumes, but we only use</pre><pre>replica mode.</pre><pre><br></pre><pre>Is anyone aware of a way to know if libgfapi is responsible or not ?</pre><pre>Does it have any kind of reporting I could enable ? Worse case I could</pre><pre>always boot a VM through the fuse mount instead of libgfapi, but that's</pre><pre>not ideal, it'd take a while to confirm.</pre><pre><br></pre><pre><br></pre><pre>_______________________________________________</pre><pre>Gluster-users mailing list</pre><pre><a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a></pre><pre><a href="https://lists.gluster.org/mailman/listinfo/gluster-users">https://lists.gluster.org/mailman/listinfo/gluster-users</a></pre></blockquote><div><span><pre><pre>-- <br></pre>James P. Kinney III
Every time you stop a school, you will have to build a jail. What you
gain at one end you lose at the other. It's like feeding a dog on his
own tail. It won't fatten the dog.
- Speech 11/23/1900 Mark Twain
http://heretothereideas.blogspot.com/
</pre></span></div></body></html>