<div dir="ltr"><div dir="ltr">On Sun, Apr 11, 2021 at 10:29 AM Amar Tumballi &lt;<a href="mailto:amar@kadalu.io">amar@kadalu.io</a>&gt; wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Hi Marco, this is really good test/info. Thanks.<div dir="auto"><br></div><div dir="auto">One more thing to observe is you are running such tests is &#39;gluster profile info&#39;, so the bottleneck fop is listed.</div><div dir="auto"><br></div><div dir="auto">Mohit, Xavi, in this parallel operations, the load may be high due to inodelk used in mds xattr update in dht? Or you guys suspect something else?</div></div></blockquote><div><br></div><div>A profile info would be very useful to know which fop gets more requests. I think inodelk by itself shouldn&#39;t be an issue (I guess we are setting mds only once, right ?). In theory we shouldn&#39;t be sending any operation on an inode without a previous successful lookup, and in this case lookups should fail, so I don&#39;t clearly see what&#39;s the difference compared to an stat.</div><div><br></div><div>We should investigate this. I&#39;ll try to do some experiments (not sure if this week, though).</div><div><br></div><div>Regards,</div><div><br></div><div>Xavi</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"><br></div><div dir="auto">Regards</div><div dir="auto">Amar</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 10 Apr, 2021, 11:45 pm Marco Lerda - FOREACH S.R.L., &lt;<a href="mailto:marco.lerda@foreach.it" target="_blank">marco.lerda@foreach.it</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">hi,<br>
we have isolated the problem (meanwhile some hardware upgrade and code <br>
optimization helped to limit the problem).<br>
it happens when many request (HTTP over apache) comes to a non existent <br>
file.<br>
With 30 concurrent request to the same non existing file cause the load <br>
go high without limit.<br>
Same requests on existing files works fine.<br>
I have tried to simulate che apache access to file excluding apache with <br>
repeated command on files with the same parallelism (30):<br>
- with ls works fine, file exists or not<br>
- with stat works fine, file exists or not<br>
- with xattr load go up, file exists or not<br>
<br>
thank you<br>
<br>
<br>
Il 05/10/2020 19.45, Marco Lerda - FOREACH S.R.L. ha scritto:<br>
&gt; hi,<br>
&gt; we use glusterfs on a php application that have many small php files <br>
&gt; images etc...<br>
&gt; We use glusterfs in replication mode.<br>
&gt; We have 2 nodes connected in fiber with 100MBps and less than 1 ms <br>
&gt; latency.<br>
&gt; We have also an arbiter on slower network (but the issue is there also <br>
&gt; without the arbiter).<br>
&gt; When we copy a directory (cp command) with many files, cpu usage and <br>
&gt; load explode raplidly,<br>
&gt; our application become inaccessible until the copy ends.<br>
&gt;<br>
&gt; I wonder if is that normal or we have done something wrong.<br>
&gt; I know that glusterfs is not indicated with many small files, and I <br>
&gt; know that it slow down,<br>
&gt; but I want to avoid that a simple copy of a directory will put down <br>
&gt; out application.<br>
&gt;<br>
&gt; Any suggestion?<br>
&gt;<br>
&gt; Thanks a lot<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; ________<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Community Meeting Calendar:<br>
&gt;<br>
&gt; Schedule -<br>
&gt; Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC<br>
&gt; Bridge: <a href="https://bluejeans.com/441850968" rel="noreferrer noreferrer" target="_blank">https://bluejeans.com/441850968</a><br>
&gt;<br>
&gt; Gluster-users mailing list<br>
&gt; <a href="mailto:Gluster-users@gluster.org" rel="noreferrer" target="_blank">Gluster-users@gluster.org</a><br>
&gt; <a href="https://lists.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-users</a><br>
<br>
-- <br>
<br>
------------------------------------------------------<br>
Marco Lerda<br>
FOREACH S.R.L.<br>
Via Laghi di Avigliana 115, 12022 - Busca (CN)<br>
Telefono: 0171-1984102<br>
Centralino/Fax: 0171-1984100<br>
Email:  <a href="mailto:marco.lerda@foreach.it" rel="noreferrer" target="_blank">marco.lerda@foreach.it</a><br>
Web: <a href="http://www.foreach.it" rel="noreferrer noreferrer" target="_blank">http://www.foreach.it</a><br>
<br>
________<br>
<br>
<br>
<br>
Community Meeting Calendar:<br>
<br>
Schedule -<br>
Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC<br>
Bridge: <a href="https://meet.google.com/cpu-eiue-hvk" rel="noreferrer noreferrer" target="_blank">https://meet.google.com/cpu-eiue-hvk</a><br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org" rel="noreferrer" target="_blank">Gluster-users@gluster.org</a><br>
<a href="https://lists.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-users</a><br>
</blockquote></div>
-------<br>
<br>
Community Meeting Calendar:<br>
Schedule -<br>
Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC<br>
Bridge: <a href="https://meet.google.com/cpu-eiue-hvk" rel="noreferrer" target="_blank">https://meet.google.com/cpu-eiue-hvk</a><br>
<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
<a href="https://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-devel</a><br>
<br>
</blockquote></div></div>