On Fri, Jul 29, 2016 at 10:09 PM, Pranith Kumar Karampuri <
pkarampu at redhat.com> wrote:
>
>
> On Fri, Jul 29, 2016 at 2:26 PM, Yannick Perret <
> yannick.perret at liris.cnrs.fr> wrote:
>
>> Ok, last try:
>> after investigating more versions I found that FUSE client leaks memory
>> on all of them.
>> I tested:
>> - 3.6.7 client on debian 7 32bit and on debian 8 64bit (with 3.6.7
>> serveurs on debian 8 64bit)
>> - 3.6.9 client on debian 7 32bit and on debian 8 64bit (with 3.6.7
>> serveurs on debian 8 64bit)>> - 3.7.13 client on debian 8 64bit
(with 3.8.1 serveurs on debian 8 64bit)
>> - 3.8.1 client on debian 8 64bit (with 3.8.1 serveurs on debian 8
64bit)
>> In all cases compiled from sources, appart for 3.8.1 where .deb were
used
>> (due to a configure runtime error).
>> For 3.7 it was compiled with --disable-tiering. I also tried to compile
>> with --disable-fusermount (no change).
>>
>> In all of these cases the memory (resident & virtual) of glusterfs
>> process on client grows on each activity and never reach a max (and
never
>> reduce).
>> "Activity" for these tests is cp -Rp and ls -lR.
>> The client I let grows the most overreached ~4Go RAM. On smaller
machines
>> it ends by OOM killer killing glusterfs process or glusterfs dying due
to
>> allocation error.
>>
>> In 3.6 mem seems to grow continusly, whereas in 3.8.1 it grows by
"steps"
>> (430400 ko ? 629144 (~1min) ? 762324 (~1min) ? 827860?).
>>
>> All tests performed on a single test volume used only by my test
client.
>> Volume in a basic x2 replica. The only parameters I changed on this
volume
>> (without any effect) are diagnostics.client-log-level set to ERROR and
>> network.inode-lru-limit set to 1024.
>>
>
> Could you attach statedumps of your runs?
> The following link has steps to capture this(
> https://gluster.readthedocs.io/en/latest/Troubleshooting/statedump/ ). We
> basically need to see what are the memory types that are increasing. If you
> could help find the issue, we can send the fixes for your workload. There
> is a 3.8.2 release in around 10 days I think. We can probably target this
> issue for that?
>
hi,
We found a problem here:
https://bugzilla.redhat.com/show_bug.cgi?id=1361681#c0, Based on git-blame
this bug is in existence from 2012-Aug may be even longer. I am wondering
if you guys are running into this. Do you guys want to help test the fix if
we provide this? I don't think lot of others ran into this problem I guess.
>
>
>>
>> This clearly prevent us to use glusterfs on our clients. Any way to
>> prevent this to happen? I still switched back to NFS mounts but it is
not
>> what we're looking for.
>>
>> Regards,
>> --
>> Y.
>>
>>
>>
>> _______________________________________________
>> Gluster-users mailing list
>> Gluster-users at gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-users
>>
>
>
>
> --
> Pranith
>
--
Pranith
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.gluster.org/pipermail/gluster-users/attachments/20160729/880f8a95/attachment.html>