Bug 1577750 - severe drop in response time of simultaneous lookups with other-eager-lock enabled
Summary: severe drop in response time of simultaneous lookups with other-eager-lock en...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: disperse
Version: rhgs-3.4
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: ---
: ---
Assignee: Ashish Pandey
QA Contact: Upasana
URL:
Whiteboard:
Depends On: 1598056 1558989
Blocks: 1610751 1611151 1651508
TreeView+ depends on / blocked
 
Reported: 2018-05-14 06:07 UTC by nchilaka
Modified: 2019-07-08 20:13 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1610751 (view as bug list)
Environment:
Last Closed: 2018-11-19 09:53:54 UTC


Attachments (Terms of Use)
screenshot with showing the performance with 3.12.2-11 build (143.19 KB, image/png)
2018-05-18 12:05 UTC, nchilaka
no flags Details

Description nchilaka 2018-05-14 06:07:16 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 5 nchilaka 2018-05-18 12:05:39 UTC
Created attachment 1438519 [details]
screenshot with showing the performance with 3.12.2-11 build

Comment 31 Anand Paladugu 2018-08-06 10:44:27 UTC
The plan is to turn of eager lock off by default using 1611151 and only turn it on only in cases where it is needed.

Comment 33 Ashish Pandey 2018-10-30 09:01:08 UTC
To debug the real issue with other.eager-lock enable, I would again request QE to test it with latest release as there are some patches related to performance  and that could have fixed the issue.

There was nothing in EC which would have impacted the performance. As per comment  #25 we are seeing high inodelk latency on brick side.

Comment 34 Atin Mukherjee 2018-11-09 07:57:43 UTC
1. Do we have plan to enable other eager lock in future?
2. If we do enable it for certain cases, then do we a perf hit? If not keeping this bug open doesn't make much sense to me.


Note You need to log in before you can comment on or make changes to this bug.