hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amir Langer (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-5453) Support fine grain locking in FSNamesystem
Date Mon, 30 Dec 2013 08:48:56 GMT

    [ https://issues.apache.org/jira/browse/HDFS-5453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858664#comment-13858664

Amir Langer commented on HDFS-5453:

The ASYNC performance of get block locations with 15, 16 threads is poor because of CPU thrashing.
Remember that these results were obtained on an 8 core machine. With 16 worker threads, 16
clients and one very important scheduler thread all competing for the same cores - It is not
that surprising that it performed so poorly.
The impact on the scheduler thread is especially critical because any time it is swapped,
it impacts the throughput of all.
On a real async service I would expect much tighter control of the resources using patterns
such as core isolation, thread affinity or at least setting a different thread priority.

Back to this JIRA :) - 

I think you're right and have linked HDFS-5477 to this JIRA. 

The plan in HDFS-5477 is not to redesign the whole thing - so consistency will still rely
on locking and therefore this JIRA  is required. On a different test we conducted, fine grained
locking outperformed the current global lock by quite a margin when an (artificial) 1ms delay
was introduced into a create operation. This showed us that without it, we can not introduce
an RPC call into the locked parts of the namesystem.


> Support fine grain locking in FSNamesystem
> ------------------------------------------
>                 Key: HDFS-5453
>                 URL: https://issues.apache.org/jira/browse/HDFS-5453
>             Project: Hadoop HDFS
>          Issue Type: New Feature
>          Components: namenode
>    Affects Versions: 2.0.0-alpha, 3.0.0
>            Reporter: Daryn Sharp
>            Assignee: Daryn Sharp
>         Attachments: async_simulation.xlsx
> The namesystem currently uses a course grain lock to control access.  This prevents concurrent
writers in different branches of the tree, and prevents readers from accessing branches that
writers aren't using.
> Features that introduce latency to namesystem operations, such as cold storage of inodes,
will need fine grain locking to avoid degrading the entire namesystem's throughput.

This message was sent by Atlassian JIRA

View raw message