Bug 1610751

Summary: severe drop in response time of simultaneous lookups with other-eager-lock enabled
Product: [Community] GlusterFS Reporter: Ashish Pandey <aspandey>
Component: disperseAssignee: bugs <bugs>
Status: CLOSED WONTFIX QA Contact:
Severity: urgent Docs Contact:
Priority: unspecified    
Version: mainlineCC: amukherj, aspandey, bugs, jahernan, nchilaka, rcyriac, rhs-bugs, sankarshan, storage-qa-internal, ubansal, vdas
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1577750
: 1651508 (view as bug list) Environment:
Last Closed: 2018-11-20 09:09:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1558989, 1577750, 1598056    
Bug Blocks:    

Comment 1 Ashish Pandey 2018-08-01 11:33:47 UTC
Description of problem:
-------------------
when I do a simultaneous lookups using ls from multiple clients, the time taken to  complete the listing by the last client takes about 11 seconds(other clients varying from 0.5sec to 8sec). this is in case of a disperse volume mounted on 4 fuse clients.
However If i disable other-eager-lock, the response time is almost similar and immediate for all 4 clients ie less than 1 second

This is a serious drop in performance given that the root of volume had about only 4 directories to be looked up for.

note that this discussion has been going on for sometime in BZ#1530519

Version-Release number of selected component (if applicable):
-------------------
3.12.2-8

How reproducible:
============
always

Steps to Reproduce:
1.create an ec volume say 2x(4+2)
2.mount volume on a client and create 4 entries say 4 directories on root
3.now mount volume on another 3 clients
4. from all clients parallelly issue ls
5. now turn of other-eager-lock and re-issue ls parallelly

Actual results:
-------------
while with step 5 the response by all clients is similar and less than a second,
with step4 the response time for the last client is as huge as 11sec

Workaround:
Turn off other-eager lock by default

Comment 2 Worker Ant 2018-08-01 11:35:31 UTC
REVIEW: https://review.gluster.org/20605 (cluster/ec: Keep others.eager-lock off by default) posted (#2) for review on master by Ashish Pandey

Comment 3 Ashish Pandey 2018-11-20 09:09:16 UTC
There is a patch which sends lock contention notification to clients.
It will solve the performance issue cause by others.eager-lock enabled.

Closing this bug now.