[
https://issues.apache.org/jira/browse/HDFS-9952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15200902#comment-15200902
]
Vinayakumar B commented on HDFS-9952:
-------------------------------------
{quote}In this case, the time frame of holding MutableRate lock is short. What
it does inside the lock is simple algebraic calculation. But assume fsWriteLock
is just released, and many threads are waiting at the entrance of fsReadLock.
If MutableRate lock is the first thing inside the door of fsReadLock, then
there's lots contention for MutableRate lock once those threads get inside the
door at the same time.
What if we save the value at ThreadLocal, and after we release the fsReadLock,
we add it to metrics? ThreadLocal is lock free.{quote}
Thanks for the pointers [~walter.k.su].
Updated the patch.
> Expose FSNamesystem lock wait time as metrics
> ---------------------------------------------
>
> Key: HDFS-9952
> URL: https://issues.apache.org/jira/browse/HDFS-9952
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: namenode
> Reporter: Vinayakumar B
> Assignee: Vinayakumar B
> Attachments: HDFS-9952-01.patch, HDFS-9952-02.patch,
> HDFS-9952-03.patch
>
>
> Expose FSNameSystem's readlock() and writeLock() wait time as metrics.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
