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

[Yanfei Wang]

Thanks for you kind reply, which is very helpful for me, I use 3.11,

Thanks a lot.  :-)

- Fei
On Thu, Jun 7, 2018 at 6:59 PM Poornima Gurusiddaiah
<pgurusid at redhat.com> wrote:
>
> 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