<div dir="ltr">On Wed, Sep 6, 2017 at 10:27 AM, Raghavendra G <span dir="ltr">&lt;<a href="mailto:raghavendra@gluster.com" target="_blank">raghavendra@gluster.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra">Also we&#39;ve an article for sysadmins which has a section:<br><pre>&lt;quote&gt;<br></pre><pre>With GlusterFS, many users with a lot of storage and many small files
easily end up using a lot of RAM on the server side </pre></div></blockquote><div><br></div><div>I think this article speaks about bricks. We can have similar recommendations for clients having fuse mount of glusterfs.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><pre>due to
&#39;inode/dentry&#39; caching, leading to decreased performance when the kernel
keeps crawling through data-structures on a 40GB RAM system. Changing
this value higher than 100 has helped many users to achieve fair caching
and more responsiveness from the kernel.<br><br>&lt;/quote&gt;<br><br></pre><pre>Complete article can be found at:<br><a href="https://gluster.readthedocs.io/en/latest/Administrator%20Guide/Linux%20Kernel%20Tuning/" target="_blank">https://gluster.readthedocs.<wbr>io/en/latest/Administrator%<wbr>20Guide/Linux%20Kernel%<wbr>20Tuning/</a><br><br></pre><br clear="all"></div></blockquote></div><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Raghavendra G<br></div>
</div></div>