If you are not using applications that rely on 100% metadata consistency, like Databases, Kafka, AMQ etc. you can use the below mentioned volume options:
# gluster volume set <volname> group metadata-cache # gluster volume set <volname> network.inode-lru-limit 200000 # gluster volume set <VOLNAME> performance.readdir-ahead on # gluster volume set <VOLNAME> performance.parallel-readdir on For more information refer to [1] Also, which version og Gluster are you using? Its preferred to use 3.11 or above for these perf enhancements. Note that parallel-readdir is going to help in increasing the ls -l performance drastically in your case, but there are few corner case known issues. Regards, Poornima [1] https://github.com/gluster/glusterdocs/pull/342/files#diff-62f536ad33b2c2210d023b0cffec2c64 On Wed, May 30, 2018, 8:29 PM Yanfei Wang <back...@gmail.com> wrote: > Hi experts on glusterFS, > > In our testbed, we found that the ' ls -l' performance is pretty slow. > Indeed from the prospect of glusterFS design space, we need to avoid > 'ls ' directory which will traverse all bricks sequentially in our > current knowledge. > > We use generic setting for our testbed: > > ``` > Volume Name: gv0 > Type: Distributed-Replicate > Volume ID: 4a6f96f8-b3fb-4550-bd19-e1a5dffad4d0 > Status: Started > Snapshot Count: 0 > Number of Bricks: 19 x 3 = 57 > Transport-type: tcp > Bricks: > ... > Options Reconfigured: > features.inode-quota: off > features.quota: off > cluster.quorum-reads: on > cluster.quorum-count: 2 > cluster.quorum-type: fixed > transport.address-family: inet > nfs.disable: on > performance.client-io-threads: off > cluster.server-quorum-ratio: 51% > > ``` > > Carefully consulting docs, the NFS client is preferred client solution > for better 'ls' performance. However, this better performance comes > from caching meta info locally, I think, and the caching mechanism > will cause the penalty of data coherence, right? > > I want to know what's the best or mature way to trade-off the 'ls ' > performance with data coherence in in reality? Any comments are > welcome. > > Thanks. > > -Fei > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://lists.gluster.org/mailman/listinfo/gluster-devel >
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel