[Gluster-devel] performance seems extremely bad

Dale Dude dale at oc3networks.com
Fri Jul 20 00:26:25 UTC 2007


See my email subjected:
"mainline-2.5 performance a known issue?"


Anand Avati wrote:
> Dale,
>  it is tough to relate the performance numbers provided by dbench to 
> actual real-life application's "performance" over a filesystem. dbench 
> usually reports very low numbers on filesystem implementations via 
> fuse, due to the marginally increased latency for every meta data 
> operation. But for real life applications the perfrmance is almost as 
> good as a local disk and sometimes better for very heavy I/O. Can you 
> compare the dbench numbers (on the latest TLA patchset) with, say, NFS 
> or other similar network filesystems?
>
> thanks,
> avati
>
> 2007/7/5, Dale Dude <dale at oc3networks.com <mailto:dale at oc3networks.com>>:
>
>     Kernel 2.6.15. mainline-2.5 patch 275. fuse 2.6.5
>
>     Tested with: dbench -t 10 10. Is performance supposed to be this bad?
>
>     Glusterfs /volumes: Throughput 15.8983 MB/sec 10 procs
>
>     Bypass glusterfs direct to /volume1: Throughput 65.0482 MB/sec 10
>     procs
>
>     Bypass glusterfs direct to /volume2: Throughput 66.5139 MB/sec 10
>     procs
>
>
>
>     =============
>     client.vol:
>
>     volume server1
>              type protocol/client
>              option transport-type tcp/client     # for TCP/IP transport
>              option remote-host 127.0.0.1 <http://127.0.0.1>     # IP
>     address of the remote brick
>              option remote-subvolume volumenamespace
>     end-volume
>
>     volume server1vol1
>              type protocol/client
>              option transport-type tcp/client     # for TCP/IP transport
>              option remote-host 127.0.0.1 <http://127.0.0.1>     # IP
>     address of the remote brick
>              option remote-subvolume clusterfs1
>     end-volume
>
>
>     volume server1vol2
>              type protocol/client
>              option transport-type tcp/client     # for TCP/IP transport
>              option remote-host 127.0.0.1 <http://127.0.0.1>      # IP
>     address of the remote brick
>              option remote-subvolume clusterfs2
>     end-volume
>
>     volume bricks
>       type cluster/unify
>       option namespace server1
>       option readdir-force-success on  # ignore failed mounts
>       subvolumes server1vol1 server1vol2
>
>       option scheduler rr
>       option rr.limits.min-free-disk 5 #%
>     end-volume
>
>     volume writebehind   #writebehind improves write performance a lot
>       type performance/write-behind
>       option aggregate-size 131072 # in bytes
>       subvolumes bricks
>     end-volume
>
>     volume readahead
>       type performance/read-ahead
>       option page-size 65536     # unit in bytes
>       option page-count 16       # cache per file  = (page-count x
>     page-size)
>       subvolumes writebehind
>     end-volume
>
>     volume iothreads
>        type performance/io-threads
>        option thread-count 32
>        subvolumes readahead
>     end-volume
>
>     ==============================
>     server.vol :
>
>     volume volume1
>       type storage/posix
>       option directory /volume1
>     end-volume
>
>     #volume posixlocks1
>       #type features/posix-locks
>       #option mandatory on          # enables mandatory locking on all
>     files
>       #subvolumes volume1
>     #end-volume
>
>     volume clusterfs1
>        type performance/io-threads
>        option thread-count 16
>        subvolumes volume1
>     end-volume
>
>     #######
>
>     volume volume2
>       type storage/posix
>       option directory /volume2
>     end-volume
>
>     #volume posixlocks2
>       #type features/posix-locks
>       #option mandatory on          # enables mandatory locking on all
>     files
>       #subvolumes volume2
>     #end-volume
>
>     volume clusterfs2
>        type performance/io-threads
>        option thread-count 16
>        subvolumes volume2
>     end-volume
>
>     #######
>
>     volume volumenamespace
>       type storage/posix
>       option directory /volume.namespace
>     end-volume
>
>     ###
>
>     volume clusterfs
>       type protocol/server
>       option transport-type tcp/server
>       subvolumes clusterfs1 clusterfs2 volumenamespace
>       option auth.ip.clusterfs1.allow *
>       option auth.ip.clusterfs2.allow *
>       option auth.ip.volumenamespace.allow *
>     end-volume
>
>
>     _______________________________________________
>     Gluster-devel mailing list
>     Gluster-devel at nongnu.org <mailto:Gluster-devel at nongnu.org>
>     http://lists.nongnu.org/mailman/listinfo/gluster-devel
>
>
>
>
> -- 
> Anand V. Avati 



More information about the Gluster-devel mailing list