<div dir="ltr">Update for the last mail:<div style>In order to reproduce the issue "<span style="font-size:12.727272033691406px;color:rgb(80,0,80);font-family:arial,sans-serif">wait_forward_request(167) poll timeout 1</span>", we do our test with 100M switch. We can reproduce the issue every time with sequential write on a large file (in our case, 10GB).</div>
<div style> We notice the number of threads reaches ~70 and the network bandwidth is saturated (~90Mbps).</div><div style><br></div><div style>I have no idea the internal implementation and just wondering can this be improved to avoid so frequent poll timeout? Because this is a common case when the switch is slow.</div>
<div style><br></div><div style>best,</div><div style><br></div><div style>Hongyi</div><div><br></div><div><br><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 23, 2013 at 1:26 AM, Hongyi Wang <span dir="ltr"><<a href="mailto:h@zelin.io" target="_blank">h@zelin.io</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Hi,<br><br>I did some I/O tests on 4-node cluster these days. I used fio micro benchmark. It works perfectly and the I/O performance is reasonably good except the following two scenarios:<br>
<br>1. Recovery <br><br>I noticed recovery occurs as soon as any node joins or quits the cluster. I know triggering recovery as early as possible can make sure data more reliable since replica are reconstructed earlier. But the recovery consume huge both disk and network bandwidth, which heavily hurts guest vm I/O. <br>
<br>2. Intensive I/O<br><br>Vm performing some big I/O is fail. In my case, I use fio micro benchmark to generate a big file (size=10g), then read and write the file randomly(bs=4m), the vm is hang and on its host machine, the sheep.log shows:<br>
May 23 07:22:07 [gway 28664] wait_forward_request(167) poll timeout 1<br>May 23 07:22:08 [gway 28666] wait_forward_request(167) poll timeout 1<br>May 23 07:22:09 [gway 28668] wait_forward_request(167) poll timeout 1<br>May 23 07:22:09 [gway 28669] wait_forward_request(167) poll timeout 1<br>
......<br>But if I tried small file size, say 128m, no poll timeout log output. <br><br></div></div>For 1, I think two better policies can be applied: a) allocating fixed bandwidth for recovery operation so as not to consume all bandwidth resource; b) initialize recovery lazily which can prevent with thrashing when nodes join or quit frequently. <br>
<div class="HOEnZb"><div class="h5"><br>For 2, I have no idea why this happened. I wonder what causes poll timeout.<br><br>Thanks,<br><br>--Hongyi</div></div><br>--<br>
sheepdog mailing list<br>
<a href="mailto:sheepdog@lists.wpkg.org">sheepdog@lists.wpkg.org</a><br>
<a href="http://lists.wpkg.org/mailman/listinfo/sheepdog" target="_blank">http://lists.wpkg.org/mailman/listinfo/sheepdog</a><br>
<br></blockquote></div><br></div>