<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 8, 2017 at 12:49 PM, Pranith Kumar Karampuri <span dir="ltr">&lt;<a href="mailto:pkarampu@redhat.com" target="_blank">pkarampu@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Fri, Jun 2, 2017 at 1:01 AM, Serkan Çoban <span dir="ltr">&lt;<a href="mailto:cobanserkan@gmail.com" target="_blank">cobanserkan@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_5118311249502366793gmail-">&gt;Is it possible that this matches your observations ?<br>
</span>Yes that matches what I see. So 19 files is being in parallel by 19<br>
SHD processes. I thought only one file is being healed at a time.<br>
Then what is the meaning of disperse.shd-max-threads parameter? If I<br>
set it to 2 then each SHD thread will heal two files at the same time?<br></blockquote><div><br></div></span><div>Yes that is the idea.<br></div></div></div></div></blockquote><div><br></div><div>One small correction. So if you have n*(16+4) and the server has at least one brick contributing to these n subvolumes, then the number of heals it will do will be &#39;n&#39; and if you set the max-threads to 2 then it will be 2n. So the option is per EC subvolume.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="m_5118311249502366793gmail-"><br>
&gt;How many IOPS can handle your bricks ?<br>
</span>Bricks are 7200RPM NL-SAS disks. 70-80 random IOPS max. But write<br>
pattern seems sequential, 30-40MB bulk writes every 4-5 seconds.<br>
This is what iostat shows.<br>
<span class="m_5118311249502366793gmail-"><br>
&gt;Do you have a test environment where we could check all this ?<br>
</span>Not currently but will have in 4-5 weeks. New servers are arriving, I<br>
will add this test to my notes.<br>
<span class="m_5118311249502366793gmail-"><br>
&gt; There&#39;s a feature to allow to configure the self-heal block size to optimize these cases. The feature is available on 3.11.<br>
</span>I did not see this in 3.11 release notes, what parameter name I should look for?<br></blockquote></span><div><br>disperse.self-heal-window-size<br><br><br>+    { .key  = {&quot;self-heal-window-size&quot;},<br>+        .type = GF_OPTION_TYPE_INT,<br>+        .min  = 1,<br>+        .max  = 1024,<br>+        .default_value = &quot;1&quot;,<br>+        .description = &quot;Maximum number blocks(128KB) per file for which &quot;<br>+                       &quot;self-heal process would be applied simultaneously.&quot;<br>+    },<br><br></div><div>This is the patch: <a href="https://review.gluster.org/17098" target="_blank">https://review.gluster.org/<wbr>17098</a><br></div><div><br></div><div>+Sunil,<br></div><div>     Could you add this to release notes please?<br> </div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="m_5118311249502366793gmail-HOEnZb"><div class="m_5118311249502366793gmail-h5"><br>
<br>
<br>
On Thu, Jun 1, 2017 at 10:30 AM, Xavier Hernandez &lt;<a href="mailto:xhernandez@datalab.es" target="_blank">xhernandez@datalab.es</a>&gt; wrote:<br>
&gt; Hi Serkan,<br>
&gt;<br>
&gt; On 30/05/17 10:22, Serkan Çoban wrote:<br>
&gt;&gt;<br>
&gt;&gt; Ok I understand that heal operation takes place on server side. In<br>
&gt;&gt; this case I should see X KB<br>
&gt;&gt;  out network traffic from 16 servers and 16X KB input traffic to the<br>
&gt;&gt; failed brick server right? So that process will get 16 chunks<br>
&gt;&gt; recalculate our chunk and write it to disk.<br>
&gt;<br>
&gt;<br>
&gt; That should be the normal operation for a single heal.<br>
&gt;<br>
&gt;&gt; The problem is I am not seeing such kind of traffic on servers. In my<br>
&gt;&gt; configuration (16+4 EC) I see 20 servers are all have 7-8MB outbound<br>
&gt;&gt; traffic and none of them has more than 10MB incoming traffic.<br>
&gt;&gt; Only heal operation is happening on cluster right now, no client/other<br>
&gt;&gt; traffic. I see constant 7-8MB write to healing brick disk. So where is<br>
&gt;&gt; the missing traffic?<br>
&gt;<br>
&gt;<br>
&gt; Not sure about your configuration, but probably you are seeing the result of<br>
&gt; having the SHD of each server doing heals. That would explain the network<br>
&gt; traffic you have.<br>
&gt;<br>
&gt; Suppose that all SHD but the one on the damaged brick are working. In this<br>
&gt; case 19 servers will peek 16 fragments each. This gives 19 * 16 = 304<br>
&gt; fragments to be requested. EC balances the reads among all available<br>
&gt; servers, and there&#39;s a chance (1/19) that a fragment is local to the server<br>
&gt; asking it. So we&#39;ll need a total of 304 - 304 / 19 = 288 network requests,<br>
&gt; 288 / 19 = 15.2 sent by each server.<br>
&gt;<br>
&gt; If we have a total of 288 requests, it means that each server will answer<br>
&gt; 288 / 19 = 15.2 requests. The net effect of all this is that each healthy<br>
&gt; server is sending 15.2*X bytes of data and each server is receiving 15.2*X<br>
&gt; bytes of data.<br>
&gt;<br>
&gt; Now we need to account for the writes to the damaged brick. We have 19<br>
&gt; simultaneous heals. This means that the damaged brick will receive 19*X<br>
&gt; bytes of data, and each healthy server will send X additional bytes of data.<br>
&gt;<br>
&gt; So:<br>
&gt;<br>
&gt; A healthy server receives 15.2*X bytes of data<br>
&gt; A healthy server sends 16.2*X bytes of data<br>
&gt; A damaged server receives 19*X bytes of data<br>
&gt; A damaged server sends few bytes of data (communication and synchronization<br>
&gt; overhead basically)<br>
&gt;<br>
&gt; As you can see, in this configuration each server has almost the same amount<br>
&gt; of inbound and outbound traffic. Only big difference is the damaged brick,<br>
&gt; that should receive a little more of traffic, but it should send much less.<br>
&gt;<br>
&gt; Is it possible that this matches your observations ?<br>
&gt;<br>
&gt; There&#39;s one more thing to consider here, and it&#39;s the apparent low<br>
&gt; throughput of self-heal. One possible thing to check is the small size and<br>
&gt; random behavior of the requests.<br>
&gt;<br>
&gt; Assuming that each request has a size of ~128 / 16 = 8KB, at a rate of ~8<br>
&gt; MB/s the servers are processing ~1000 IOPS. Since requests are going to 19<br>
&gt; different files, even if each file is accessed sequentially, the real effect<br>
&gt; will be like random access (some read-ahead on the filesystem can improve<br>
&gt; reads a bit, but writes won&#39;t benefit so much).<br>
&gt;<br>
&gt; How many IOPS can handle your bricks ?<br>
&gt;<br>
&gt; Do you have a test environment where we could check all this ? if possible<br>
&gt; it would be interesting to have only a single SHD (kill all SHD from all<br>
&gt; servers but one). In this situation, without client accesses, we should see<br>
&gt; the 16/1 ratio of reads vs writes on the network. We should also see a<br>
&gt; similar of even a little better speed because all reads and writes will be<br>
&gt; sequential, optimizing available IOPS.<br>
&gt;<br>
&gt; There&#39;s a feature to allow to configure the self-heal block size to optimize<br>
&gt; these cases. The feature is available on 3.11.<br>
&gt;<br>
&gt; Best regards,<br>
&gt;<br>
&gt; Xavi<br>
&gt;<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Tue, May 30, 2017 at 10:25 AM, Ashish Pandey &lt;<a href="mailto:aspandey@redhat.com" target="_blank">aspandey@redhat.com</a>&gt;<br>
&gt;&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; When we say client side heal or server side heal, we basically talking<br>
&gt;&gt;&gt; about<br>
&gt;&gt;&gt; the side which &quot;triggers&quot; heal of a file.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 1 - server side heal - shd scans indices and triggers heal<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 2 - client side heal - a fop finds that file needs heal and it triggers<br>
&gt;&gt;&gt; heal<br>
&gt;&gt;&gt; for that file.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Now, what happens when heal gets triggered.<br>
&gt;&gt;&gt; In both  the cases following functions takes part -<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; ec_heal =&gt; ec_heal_throttle=&gt;ec_launch_he<wbr>al<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Now ec_launch_heal just creates heal tasks (with ec_synctask_heal_wrap<br>
&gt;&gt;&gt; which<br>
&gt;&gt;&gt; calls ec_heal_do ) and put it into a queue.<br>
&gt;&gt;&gt; This happens on server and &quot;syncenv&quot; infrastructure which is nothing but<br>
&gt;&gt;&gt; a<br>
&gt;&gt;&gt; set of workers pick these tasks and execute it. That is when actual<br>
&gt;&gt;&gt; read/write for<br>
&gt;&gt;&gt; heal happens.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; ______________________________<wbr>__<br>
&gt;&gt;&gt; From: &quot;Serkan Çoban&quot; &lt;<a href="mailto:cobanserkan@gmail.com" target="_blank">cobanserkan@gmail.com</a>&gt;<br>
&gt;&gt;&gt; To: &quot;Ashish Pandey&quot; &lt;<a href="mailto:aspandey@redhat.com" target="_blank">aspandey@redhat.com</a>&gt;<br>
&gt;&gt;&gt; Cc: &quot;Gluster Users&quot; &lt;<a href="mailto:gluster-users@gluster.org" target="_blank">gluster-users@gluster.org</a>&gt;<br>
&gt;&gt;&gt; Sent: Monday, May 29, 2017 6:44:50 PM<br>
&gt;&gt;&gt; Subject: Re: [Gluster-users] Heal operation detail of EC volumes<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Healing could be triggered by client side (access of file) or server<br>
&gt;&gt;&gt;&gt;&gt; side<br>
&gt;&gt;&gt;&gt;&gt; (shd).<br>
&gt;&gt;&gt;&gt;&gt; However, in both the cases actual heal starts from &quot;ec_heal_do&quot;<br>
&gt;&gt;&gt;&gt;&gt; function.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; If I do a recursive getfattr operation from clients, then all heal<br>
&gt;&gt;&gt; operation is done on clients right? Client read the chunks, calculate<br>
&gt;&gt;&gt; and write the missing chunk.<br>
&gt;&gt;&gt; And If I don&#39;t access files from client then SHD daemons will start<br>
&gt;&gt;&gt; heal and read,calculate,write the missing chunks right?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; In first case EC calculations takes places in client fuse process, in<br>
&gt;&gt;&gt; second case EC calculations will be made in SHD process right?<br>
&gt;&gt;&gt; Does brick process has any role in EC calculations?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On Mon, May 29, 2017 at 3:32 PM, Ashish Pandey &lt;<a href="mailto:aspandey@redhat.com" target="_blank">aspandey@redhat.com</a>&gt;<br>
&gt;&gt;&gt; wrote:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; ______________________________<wbr>__<br>
&gt;&gt;&gt;&gt; From: &quot;Serkan Çoban&quot; &lt;<a href="mailto:cobanserkan@gmail.com" target="_blank">cobanserkan@gmail.com</a>&gt;<br>
&gt;&gt;&gt;&gt; To: &quot;Gluster Users&quot; &lt;<a href="mailto:gluster-users@gluster.org" target="_blank">gluster-users@gluster.org</a>&gt;<br>
&gt;&gt;&gt;&gt; Sent: Monday, May 29, 2017 5:13:06 PM<br>
&gt;&gt;&gt;&gt; Subject: [Gluster-users] Heal operation detail of EC volumes<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Hi,<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; When a brick fails in EC, What is the healing read/write data path?<br>
&gt;&gt;&gt;&gt; Which processes do the operations?<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Healing could be triggered by client side (access of file) or server<br>
&gt;&gt;&gt;&gt; side<br>
&gt;&gt;&gt;&gt; (shd).<br>
&gt;&gt;&gt;&gt; However, in both the cases actual heal starts from &quot;ec_heal_do&quot;<br>
&gt;&gt;&gt;&gt; function.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Assume a 2GB file is being healed in 16+4 EC configuration. I was<br>
&gt;&gt;&gt;&gt; thinking that SHD deamon on failed brick host will read 2GB from<br>
&gt;&gt;&gt;&gt; network and reconstruct its 100MB chunk and write it on to brick. Is<br>
&gt;&gt;&gt;&gt; this right?<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; You are correct about read/write.<br>
&gt;&gt;&gt;&gt; The only point is that, SHD deamon on one of the good brick will pick<br>
&gt;&gt;&gt;&gt; the<br>
&gt;&gt;&gt;&gt; index entry and heal it.<br>
&gt;&gt;&gt;&gt; SHD deamon scans the .glusterfs/index directory and heals the entries.<br>
&gt;&gt;&gt;&gt; If<br>
&gt;&gt;&gt;&gt; the brick went down while IO was going on, index will be present on<br>
&gt;&gt;&gt;&gt; killed<br>
&gt;&gt;&gt;&gt; brick also.<br>
&gt;&gt;&gt;&gt; However, if a brick was down and then you started writing on a file then<br>
&gt;&gt;&gt;&gt; in<br>
&gt;&gt;&gt;&gt; this case index entry would not be present on killed brick.<br>
&gt;&gt;&gt;&gt; So even after brick will be  UP, sdh on that brick will not be able to<br>
&gt;&gt;&gt;&gt; find<br>
&gt;&gt;&gt;&gt; it out this index. However, other bricks would have entries and shd on<br>
&gt;&gt;&gt;&gt; that<br>
&gt;&gt;&gt;&gt; brick will heal it.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Note: I am considering each brick on different node.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Ashish<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt;&gt;&gt; Gluster-users mailing list<br>
&gt;&gt;&gt;&gt; <a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>
&gt;&gt;&gt;&gt; <a href="http://lists.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">http://lists.gluster.org/mailm<wbr>an/listinfo/gluster-users</a><br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt;&gt; Gluster-users mailing list<br>
&gt;&gt;&gt; <a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>
&gt;&gt;&gt; <a href="http://lists.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">http://lists.gluster.org/mailm<wbr>an/listinfo/gluster-users</a><br>
&gt;&gt;&gt;<br>
&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt; Gluster-users mailing list<br>
&gt;&gt; <a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>
&gt;&gt; <a href="http://lists.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">http://lists.gluster.org/mailm<wbr>an/listinfo/gluster-users</a><br>
&gt;&gt;<br>
&gt;<br>
______________________________<wbr>_________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>
<a href="http://lists.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">http://lists.gluster.org/mailm<wbr>an/listinfo/gluster-users</a></div></div></blockquote></div></div></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br><div class="m_5118311249502366793gmail_signature"><div dir="ltr">Pranith<br></div></div>
</font></span></div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Pranith<br></div></div>
</div></div>