I&#39;ve got the same config (Client side AFRx2 w/write-behind) that I&#39;ve been trying to optimize for small file writes and optimization of write-behind is thus very important in my own case.&nbsp;&nbsp;&nbsp; Using DD and Postmark for benchmarking between GlusterFS 1.3.12, 2.0.0rc1 and glusterfs--mainline--3.0--patch-888&nbsp; though have seen no performance difference with and without AFR and it&#39;s tweaks.&nbsp;&nbsp; <br>
<br>Here is a link to my test config..<br><a href="http://gluster.pastebin.com/m46cb6a70">http://gluster.pastebin.com/m46cb6a70</a><br><br>Benchmarking with DD and various block sizes produces a wide range of results.. Optimally a block size of 1MB produces results of 70MB/sec.<br>
<br>4k blocks 4.3 MB/s<br>8k blocks 8.3 MB/s<br>16k blocks 15.4 MB/s<br><br>Is there a better way to tune write-behind since after a month of tinkering I still don&#39;t see any performance increase in write-behind? <br><br>
Thanks,<br><br>&nbsp;Cory<br><br><br><div class="gmail_quote">On Fri, Feb 6, 2009 at 3:09 AM, Rash <span dir="ltr">&lt;rash@konto.pl&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hey!<br>
<br>
Using write-behind translator should improve small writes performance,<br>
but using it in configuration with dht over two afrs shows to me almost<br>
none improvement. When I&#39;m watching networkt traffic (gluster works on<br>
1Gb network) for every send packet there is one recieved:<br>
<br>
10:05:20.205346 00:1e:c9:b9:bc:75 (oui Unknown) &gt; 00:1e:c9:b9:bc:39 (oui Unknown), ethertype IPv4 (0x0800), length 189: n1.1019 &gt; n2.6996: P 138505:138628(123) ack 71706 win 6533 &lt;nop,nop,timestamp 517009620 517010547&gt;<br>

10:05:20.205583 00:1e:c9:b9:bc:39 (oui Unknown) &gt; 00:1e:c9:b9:bc:75 (oui Unknown), ethertype IPv4 (0x0800), length 170: n2.6996 &gt; n1.1019: P 71706:71810(104) ack 138628 win 3027 &lt;nop,nop,timestamp 517010547 517009620&gt;<br>

10:05:20.205746 00:1e:c9:b9:bc:75 (oui Unknown) &gt; 00:1e:c9:b9:bc:39 (oui Unknown), ethertype IPv4 (0x0800), length 126: n1.1019 &gt; n2.6996: P 138628:138688(60) ack 71810 win 6533 &lt;nop,nop,timestamp 517009620 517010547&gt;<br>

10:05:20.205801 00:1e:c9:b9:bc:39 (oui Unknown) &gt; 00:1e:c9:b9:bc:75 (oui Unknown), ethertype IPv4 (0x0800), length 110: n2.6996 &gt; n1.1019: P 71810:71854(44) ack 138688 win 3027 &lt;nop,nop,timestamp 517010547 517009620&gt;<br>

10:05:20.205945 00:1e:c9:b9:bc:75 (oui Unknown) &gt; 00:1e:c9:b9:bc:39 (oui Unknown), ethertype IPv4 (0x0800), length 158: n1.1019 &gt; n2.6996: P 138688:138780(92) ack 71854 win 6533 &lt;nop,nop,timestamp 517009620 517010547&gt;<br>

10:05:20.205994 00:1e:c9:b9:bc:39 (oui Unknown) &gt; 00:1e:c9:b9:bc:75 (oui Unknown), ethertype IPv4 (0x0800), length 110: n2.6996 &gt; n1.1019: P 71854:71898(44) ack 138780 win 3027 &lt;nop,nop,timestamp 517010547 517009620&gt;<br>

10:05:20.206145 00:1e:c9:b9:bc:75 (oui Unknown) &gt; 00:1e:c9:b9:bc:39 (oui Unknown), ethertype IPv4 (0x0800), length 126: n1.1019 &gt; n2.6996: P 138780:138840(60) ack 71898 win 6533 &lt;nop,nop,timestamp 517009620 517010547&gt;<br>

10:05:20.206211 00:1e:c9:b9:bc:39 (oui Unknown) &gt; 00:1e:c9:b9:bc:75 (oui Unknown), ethertype IPv4 (0x0800), length 110: n2.6996 &gt; n1.1019: P 71898:71942(44) ack 138840 win 3027 &lt;nop,nop,timestamp 517010547 517009620&gt;<br>

10:05:20.207543 00:1e:c9:b9:bc:75 (oui Unknown) &gt; 00:1e:c9:b9:bc:39 (oui Unknown), ethertype IPv4 (0x0800), length 168: n1.1020 &gt; n2.6996: P 115271:115373(102) ack 61422 win 6161 &lt;nop,nop,timestamp 517009620 517010525&gt;<br>

10:05:20.208136 00:1e:c9:b9:bc:39 (oui Unknown) &gt; 00:1e:c9:b9:bc:75 (oui Unknown), ethertype IPv4 (0x0800), length 245: n2.6996 &gt; n1.1020: P 61422:61601(179) ack 115373 win 19825 &lt;nop,nop,timestamp 517010547 517009620&gt;<br>

10:05:20.208291 00:1e:c9:b9:bc:75 (oui Unknown) &gt; 00:1e:c9:b9:bc:39 (oui Unknown), ethertype IPv4 (0x0800), length 66: n1.1020 &gt; n2.6996: . ack 61601 win 6161 &lt;nop,nop,timestamp 517009620 517010547&gt;<br>
<br>
In config there is:<br>
<br>
volume wb<br>
 &nbsp; &nbsp; &nbsp; &nbsp;type performance/write-behind<br>
 &nbsp; &nbsp; &nbsp; &nbsp;option block-size 256kB<br>
 &nbsp; &nbsp; &nbsp; &nbsp;option cache-size 2MB<br>
 &nbsp; &nbsp; &nbsp; &nbsp;option flush-behind on<br>
 &nbsp; &nbsp; &nbsp; &nbsp;subvolumes iot<br>
end-volume<br>
<br>
So shouldn&#39;t write-behind translator agregate these small writes in one<br>
bigger - small packets in larger or larger window?<br>
<br>
Regards<br>
<font color="#888888"><br>
--<br>
rash at konto pl<br>
<br>
_______________________________________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br>
<a href="http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users" target="_blank">http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users</a><br>
</font></blockquote></div><br>