Thank you guys for the response. I've configured 2(replica) x 2 (distributed) gluster node now. The reason why I tested with 1 node is that I wanted to check primitive performance for 1 node. We wanna make subscription with RedHat but Red branch here is not supporting GlusterFS yet. So I'm asking you guys... Anyway.. I've check it larger block size using dd and iozone. (I used 4096 before) When it comes to 8192 byte or bigger as block size(record), the performance get much better like 80MB/s. So now I'm looking for* how to increase block size when JAVA app writes on file*. I've tried to increase write buffer size but it didn't make any change. I wonder if it's possible to adjust write block size for Java application. (like I did with dd tool adjusting block size..) Is there any option on java platform? or Is there any way to adjust write block size for java app? If you have any suggestion, it will be very thankful. Regards, Youngseok Jung 2013/10/26 Anand Avati <avati at gluster.org> > Also, have you specified a block size for dd? The default (512 bytes) is > too low for the number of context switches it generates in FUSE. Use a > higher block size (64-128KB) and check the throughput. > > Avati > > > On Fri, Oct 25, 2013 at 7:53 AM, Joe Julian <joe at julianfamily.org> wrote: > >> Have you brought this up with Red Hat Support? That is what you pay >> them for. >> >> >> >> Jung Young Seok <jung.youngseok at gmail.com> wrote: >> >I've wrote below email. However it seems I missed mail key word rule on >> >subject. >> >So I'm sending it again. >> >Please check the below mail and any response will be helpful. >> >Thanks, >> >2013. 10. 25. ?? 6:01? "Jung Young Seok" <jung.youngseok at gmail.com>?? >> >??: >> > >> > >> >Dear GlusterFS Engineer, >> > >> >I have questions that my glusterfs server and fuse client >> >perform properly on below specification. >> > >> >It can write only *65MB*/s through FUSE client to 1 glusterfs server (1 >> >brick and no replica for 1 volume ) >> > - NW bandwidth are enough for now. I've check it with iftop >> > - However it can write *120MB*/s when I mount nfs on the same volume. >> > >> >Could anyone check if the glusterfs and fuse client perform properly? >> > >> > >> >Detail explanations are below. >> >======================================================================= >> >I've set 4 glusterfs servers and 1 fuse client. >> >Each spec is as followings. >> > >> >*Server x 4* >> > - CPU : Intel(R) Xeon(R) CPU E5-2609 0 @ 2.40GHz (2 cpu * 4 core) >> > - Memory : 32GB >> > - HDD (3TB 7.2K RPM SATA x 14 ) >> > * RAID6(33T) >> > * XFS >> > - OS : RHS 2.1 >> > - 4 Gluster Server will be used 2 replica x 2 distributed as 1 volume >> > - NW 1G for replica >> > - NW 1G for Storage and management >> >> No need. The fuse client connects to all the servers. Replication happens >> from the client. >> >> > - Current active profile: rhs-high-throughput >> > >> >*FUSE Client (gluster 3.4)* >> > - CPU : Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz >> > - Memory : 32GB >> > - OS : CentOS6.4 >> > - NW 2G for Storage (NIC bonding) >> > >> >All server will be in 10G network. (for now 1G network) >> > >> > >> >I've tested to check primitive disk performance. >> > - on first glusterfs server >> >* it can write 870MB/s (dd if=/dev/zero of=./dummy bs=4096 count=10000) >> > * it can read 1GB/s (cat test_file.23 > /dev/null ) >> > - on fuse client (mount volume : 1 brick(1dist, no-replica) >> > * it can write 64.8MB/s >> > - on nfs client (mount volume : 1 brick(1dist, no-replica) >> > * it can write 120MB/s (it reached NW bandwith >> >> My usual question here is how does dd represent your expected use case? >> Are you comparing apples to orchards? >> >> > >> > >> >I wonder why fuse client much slower than nfs client. (it's no-replica >> peer) >> >Is it normal performance? >> >> I always max out my network connection with the fuse client, so no. It's >> not normal. >> >> >> _______________________________________________ >> Gluster-users mailing list >> Gluster-users at gluster.org >> http://supercolony.gluster.org/mailman/listinfo/gluster-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20131106/b21b1720/attachment.html>
