[Bugs] [Bug 1512460] New: disperse eager-lock degrades performance for file create workloads

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1512460

            Bug ID: 1512460
           Summary: disperse eager-lock degrades performance for file
                    create workloads
           Product: GlusterFS
           Version: 3.13
         Component: disperse
          Keywords: Triaged
          Severity: high
          Assignee: bugs at gluster.org
          Reporter: aspandey at redhat.com
                CC: bugs at gluster.org, jahernan at redhat.com,
                    mpillai at redhat.com, pkarampu at redhat.com
        Depends On: 1502610
            Blocks: 1502455



+++ This bug was initially created as a clone of Bug #1502610 +++

+++ This bug was initially created as a clone of Bug #1502455 +++

Description of problem:
The current behavior of the option disperse.eager-lock is not optimal:

disperse.eager-lock on: good performance on large-file read/write, but actually
degrades performance for many file create workloads. The degradation for file
create workloads seems to be due to lock contention on directories.

disperse.eager-lock off: loses the performance advantages of eager-locking for
large-file access, but better performance on file create workloads than with
disperse.eager-lock on.

We should fix eager locking so that it can be kept on without incurring a
performance penalty on file create workloads.

Version-Release number of selected component (if applicable):
glusterfs*-3.12.1-2.el7.x86_64

How reproducible:
Consistently

--- Additional comment from Manoj Pillai on 2017-10-16 07:32:52 CEST ---


IMO, a solution that adds a separate option to control eager locking in the
case of directories would be acceptable, and probably simple. 

So the default could be:
disperse.dir-eager-lock off: applies to directories
disperse.eager-lock on: applies to regular files

Would that work?

--- Additional comment from Xavier Hernandez on 2017-10-16 10:12:26 CEST ---

I guess this problem happens when multiple clients are creating files on the
same directory, right ? otherwise, eager-locking shouldn't interfere with file
creation (in fact it should be faster).

In cases where multiple clients access the same directory, then yes, we could
keep a separate configuration for this purpose. However, is it really necessary
to have it disabled by default ? I think that an scenario where multiple
clients are writing to the same directory is less probable than one where all
writes to a single directory come from the same client.

--- Additional comment from Worker Ant on 2017-10-16 08:00:22 EDT ---

REVIEW: https://review.gluster.org/18530 (cluster/ec: create eager-lock option
for non-regular files) posted (#1) for review on master by Xavier Hernandez
(jahernan at redhat.com)

--- Additional comment from Worker Ant on 2017-10-16 13:31:01 EDT ---

REVIEW: https://review.gluster.org/18530 (cluster/ec: create eager-lock option
for non-regular files) posted (#2) for review on master by Xavier Hernandez
(jahernan at redhat.com)

--- Additional comment from Worker Ant on 2017-11-04 23:42:21 EDT ---

COMMIT: https://review.gluster.org/18530 committed in master by  

------------- cluster/ec: create eager-lock option for non-regular files

A new option is added to allow independent configuration of eager
locking for regular files and non-regular files.

Change-Id: I8f80e46d36d8551011132b15c0fac549b7fb1c60
BUG: 1502610
Signed-off-by: Xavier Hernandez <jahernan at redhat.com>


Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1502455
[Bug 1502455] disperse eager-lock degrades performance for file create
workloads
https://bugzilla.redhat.com/show_bug.cgi?id=1502610
[Bug 1502610] disperse eager-lock degrades performance for file create
workloads
-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.