[Gluster-devel] Any mature(better) solution(way) to handle slow performance on 'ls -l, '.

[Poornima Gurusiddaiah]

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 <backyes at 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 at gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20180607/31f00271/attachment.html>