I've got the same config (Client side AFRx2 w/write-behind) that I've been trying to optimize for small file writes and optimization of write-behind is thus very important in my own case. Using DD and Postmark for benchmarking between GlusterFS 1.3.12, 2.0.0rc1 and glusterfs--mainline--3.0--patch-888 though have seen no performance difference with and without AFR and it's tweaks. Here is a link to my test config.. http://gluster.pastebin.com/m46cb6a70 Benchmarking with DD and various block sizes produces a wide range of results.. Optimally a block size of 1MB produces results of 70MB/sec. 4k blocks 4.3 MB/s 8k blocks 8.3 MB/s 16k blocks 15.4 MB/s Is there a better way to tune write-behind since after a month of tinkering I still don't see any performance increase in write-behind? Thanks, Cory On Fri, Feb 6, 2009 at 3:09 AM, Rash <rash at konto.pl> wrote: > Hey! > > Using write-behind translator should improve small writes performance, > but using it in configuration with dht over two afrs shows to me almost > none improvement. When I'm watching networkt traffic (gluster works on > 1Gb network) for every send packet there is one recieved: > > 10:05:20.205346 00:1e:c9:b9:bc:75 (oui Unknown) > 00:1e:c9:b9:bc:39 (oui > Unknown), ethertype IPv4 (0x0800), length 189: n1.1019 > n2.6996: P > 138505:138628(123) ack 71706 win 6533 <nop,nop,timestamp 517009620 > 517010547> > 10:05:20.205583 00:1e:c9:b9:bc:39 (oui Unknown) > 00:1e:c9:b9:bc:75 (oui > Unknown), ethertype IPv4 (0x0800), length 170: n2.6996 > n1.1019: P > 71706:71810(104) ack 138628 win 3027 <nop,nop,timestamp 517010547 517009620> > 10:05:20.205746 00:1e:c9:b9:bc:75 (oui Unknown) > 00:1e:c9:b9:bc:39 (oui > Unknown), ethertype IPv4 (0x0800), length 126: n1.1019 > n2.6996: P > 138628:138688(60) ack 71810 win 6533 <nop,nop,timestamp 517009620 517010547> > 10:05:20.205801 00:1e:c9:b9:bc:39 (oui Unknown) > 00:1e:c9:b9:bc:75 (oui > Unknown), ethertype IPv4 (0x0800), length 110: n2.6996 > n1.1019: P > 71810:71854(44) ack 138688 win 3027 <nop,nop,timestamp 517010547 517009620> > 10:05:20.205945 00:1e:c9:b9:bc:75 (oui Unknown) > 00:1e:c9:b9:bc:39 (oui > Unknown), ethertype IPv4 (0x0800), length 158: n1.1019 > n2.6996: P > 138688:138780(92) ack 71854 win 6533 <nop,nop,timestamp 517009620 517010547> > 10:05:20.205994 00:1e:c9:b9:bc:39 (oui Unknown) > 00:1e:c9:b9:bc:75 (oui > Unknown), ethertype IPv4 (0x0800), length 110: n2.6996 > n1.1019: P > 71854:71898(44) ack 138780 win 3027 <nop,nop,timestamp 517010547 517009620> > 10:05:20.206145 00:1e:c9:b9:bc:75 (oui Unknown) > 00:1e:c9:b9:bc:39 (oui > Unknown), ethertype IPv4 (0x0800), length 126: n1.1019 > n2.6996: P > 138780:138840(60) ack 71898 win 6533 <nop,nop,timestamp 517009620 517010547> > 10:05:20.206211 00:1e:c9:b9:bc:39 (oui Unknown) > 00:1e:c9:b9:bc:75 (oui > Unknown), ethertype IPv4 (0x0800), length 110: n2.6996 > n1.1019: P > 71898:71942(44) ack 138840 win 3027 <nop,nop,timestamp 517010547 517009620> > 10:05:20.207543 00:1e:c9:b9:bc:75 (oui Unknown) > 00:1e:c9:b9:bc:39 (oui > Unknown), ethertype IPv4 (0x0800), length 168: n1.1020 > n2.6996: P > 115271:115373(102) ack 61422 win 6161 <nop,nop,timestamp 517009620 > 517010525> > 10:05:20.208136 00:1e:c9:b9:bc:39 (oui Unknown) > 00:1e:c9:b9:bc:75 (oui > Unknown), ethertype IPv4 (0x0800), length 245: n2.6996 > n1.1020: P > 61422:61601(179) ack 115373 win 19825 <nop,nop,timestamp 517010547 > 517009620> > 10:05:20.208291 00:1e:c9:b9:bc:75 (oui Unknown) > 00:1e:c9:b9:bc:39 (oui > Unknown), ethertype IPv4 (0x0800), length 66: n1.1020 > n2.6996: . ack 61601 > win 6161 <nop,nop,timestamp 517009620 517010547> > > In config there is: > > volume wb > type performance/write-behind > option block-size 256kB > option cache-size 2MB > option flush-behind on > subvolumes iot > end-volume > > So shouldn't write-behind translator agregate these small writes in one > bigger - small packets in larger or larger window? > > Regards > > -- > rash at konto pl > > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zresearch.com/pipermail/gluster-users/attachments/20090206/1890b3e0/attachment.htm
