<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On 26 October 2015 at 14:54, Krutika Dhananjay <span dir="ltr"><<a href="mailto:kdhananj@redhat.com" target="_blank">kdhananj@redhat.com</a>></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"><div><br></div><div>Hi Lindsay,<br></div><div><br></div><div>Thank you for trying out sharding and for your feedback. :) Please find my comments inline.<br></div></blockquote><div><br></div><div>Hi Krutika, thanks for the feed back.<br> <br></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=""></span><span class=""></span><div>With block size as low as 4MB, to the replicate module, these individual shards appear as large number of small(er) files, effectively turning it into some form of a small-file workload.<br></div><div>There is an enhancement being worked on in AFR by Pranith, which attempts to improve write performance which will especially be useful when used with sharding. That should make this problem go away.<br></div></blockquote><div><br><br></div><div>Cool, also for my purposes (VM Image hosting), block sizes of 512MB are just as good and improve things considerably.<br></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></div><span class=""><div><br></div><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr"><div><div><div><div><div><div><div></div><div>One Bug:<br></div>After heals completed I shut down the VM's and run a MD5SUM on the VM image (via glusterfs) on each nodes. They all matched except for one time on gn3. Once I unmounted/remounted the datastore on gn3 the md5sum matched.</div></div></div></div></div></div></div></blockquote><div><br></div></span><div>This could possibly be the effect of a caching bug reported at <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1272986" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=1272986</a>. The fix is out for review and I'm confident that it will make it into 3.7.6.<br></div></blockquote><div><br></div><div>Cool, I can replicate it fairly reliable at the moment.<br><br></div><div>Would it occur when using qemu/gfapi direct?<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></div><span class=""><div><br></div><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr"><div><div><div><div><div><div><br><div><br></div></div>One Oddity:<br></div>gluster volume heals datastore info *always* shows a split brain on the directory, but it always heals without intervention. Dunno if this is normal on not.</div></div></div></div></div></blockquote><div><br></div></span><div>Which directory would this be? </div></blockquote><div><br></div><div>Oddly it was the .shard directory<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Do you have the glustershd logs?<br></div></blockquote><div><br></div><div>Sorry no, and I haven't managed to replicate it again. Will keep trying.<br> <br></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=""></span><div>Here is some documentation on sharding: <a>https://gluster.readthedocs.org/en/release-3.7.0/Features/shard/</a><a>. </a>Let me know if you have more questions, and I will be happy to answer them.<br></div><div>The problems we foresaw with too many 4MB shards is that</div><div>i. entry self-heal under /.shard could result in complete crawl of the /.shard directory during heal, or</div><div>ii. a disk replacement could involve lot many files needing to be created and healed to the sink brick,<br></div><div>both of which would result in slower "entry" heal and rather high resource consumption from self-heal daemon.<br></div></blockquote><div><br></div><div>Thanks, most interesting reading.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div></div><div>Fortunately, with the introduction of more granular changelogs in replicate module to identify exactly what files under a given directory need to be healed to the sink brick, these problems should go away.<br></div><div>In fact this enhancement is being worked upon as we speak and is targeted to be out by 3.8. Here is some doc: <a href="http://review.gluster.org/#/c/12257/1/in_progress/afr-self-heal-improvements.md" target="_blank">http://review.gluster.org/#/c/12257/1/in_progress/afr-self-heal-improvements.md</a> (read section "Granular entry self-heals").<br></div></blockquote><div><br></div><div>That look very interesting - in fact from my point of view, it replaces the need for sharding altogether, that being the speed of heals. <br></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=""><div><br></div></span><span class=""></span><div>Yes. So Paul Cuzner and Satheesaran who have been testing sharding here have reported better write performance with 512M shards. I'd be interested to know what you feel about performance with relatively larger shards (think 512M).</div></blockquote></div><br></div><div class="gmail_extra">Seq Read speeds basically tripled, and seq writes improved to the limit of the network connection.<br><br></div><div class="gmail_extra">Cheers,<br></div><div class="gmail_extra"><br><br clear="all"><br>-- <br><div class="gmail_signature">Lindsay</div>
</div></div>