[Gluster-users] GlusterFS fuse client read performance problem

[Satake Code]

I'm having a problem with the read performance with the native fuse client.
I can write at  250 to 300mb/s but can only read the same written file at a
maximum of 60mb/s. Is this behavior normal?
When I tried the NFS mount the speed for read and write operations are
about the same peaking both at about 300mb/s.

The tests I did were while copying to and from the mount with a 2gb, and
10gb file.

The build is 2 servers with replicated volumes, both with SSD drives under
software Raid 1, 10Gbit local ethernet with MTU 9000, 64Gb ram and 16 core
processor.

I've tried a couple different configurations on the server and currently
have the following:

Running glusterfs 3.8.5 built on Oct 20 2016 01:15:39

Volume Name: webstorage
Type: Replicate
Volume ID: 1a5924de-737c-4a3d-a195-a95ea1fc6ad6
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: srv1:/data/glusterfs/bricks/1/webstorage
Brick2: srv2:/data/glusterfs/bricks/1/webstorage
Options Reconfigured:
nfs.outstanding-rpc-limit: 128
nfs.acl: off
performance.client-io-threads: on
cluster.lookup-optimize: on
server.outstanding-rpc-limit: 128
server.event-threads: 3
client.event-threads: 3
performance.read-ahead: on
performance.io-cache: on
performance.write-behind-window-size: 1MB
performance.cache-size: 15728640
performance.io-thread-count: 32
nfs.trusted-write: on
nfs.trusted-sync: on
performance.nfs.io-cache: on
performance.nfs.stat-prefetch: on
performance.nfs.io-threads: on
performance.nfs.read-ahead: off
nfs.mem-factor: 20
transport.address-family: inet
performance.readdir-ahead: on
nfs.disable: off
auth.allow: 172.16.*.*
performance.quick-read: on
cluster.read-hash-mode: 0

The client is running the same version of GlusterFs and have the same
hardware specs as the servers.

Is there something that I'm missing for the native fuse mount to perform a
read speed comparable to the NFS mount? Or at least the same as the write
speed of the fuse mount?

Thank you,
Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20161118/e21199d2/attachment.html>