I&#39;ve never had any bloat problems with gluster except with io-cache. Right now, I have one node where the glusterfs process is taking 6.2GB RAM! with cache-size set to 3000mb. It&#39;s taking so much RAM that it&#39;s actually starting to cache stuff... into swap.<div>
<br></div><div><div> 3888     1 root        0 52.5 6.2g 7790m 1.5g 1056 8274  20   0 -         S 6  12:07 glusterfs                                           </div><div><br></div><div>Crazy. As soon as the guy I need to speak to to set up some test jobs comes in today, I&#39;m going to follow the directions posted previously to figure out if its a leak or something else.</div>
<br>Dan<br>
<br><br><div class="gmail_quote">On Tue, Feb 24, 2009 at 8:58 AM, Gordan Bobic <span dir="ltr">&lt;<a href="mailto:gordan@bobich.net">gordan@bobich.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">Dan Parsons wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I will do this today. I noticed that I already have vm.drop_caches set to 3 via sysctl.conf, based on a suggestion from you from long ago. Should I delete this under normal usage? Is it possible that this setting, enabled by default, is causing my problems?<br>

</blockquote>
<br></div>
It isn&#39;t a permanent setting, it&#39;s just a real-time instruction to drop all current caches.<br>
<br>
In the current context, I think the whole idea is bogus anyway because glusterfs process still maintains it&#39;s current resident size at hundreds of MB when I flush the caches (with no performance translators), so I don&#39;t think this affects the leak in any way.<br>

<br>
On my setup I have / mounted on glusterfs, /tmp on ext3 and /usr/src on NFS, so the fact that glusterfs root daemon bloating can only be caused either by access to shared libraries or invocation of executables, since compiling a big code tree (including when it doesn&#39;t reside on glusterfs) seems to trigger the leak in a pretty major way.<br>

<br>
I&#39;ll try to re-create the problem with a chroot environment, since debuging the rootfs daemon is extremely difficult.<div><div></div><div class="Wj3C7c"><br>
<br>
Gordan<br>
<br>
<br>
_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@nongnu.org" target="_blank">Gluster-devel@nongnu.org</a><br>
<a href="http://lists.nongnu.org/mailman/listinfo/gluster-devel" target="_blank">http://lists.nongnu.org/mailman/listinfo/gluster-devel</a><br>
</div></div></blockquote></div><br></div>