Erik Krogen commented on HDFS-10872:

[~andrew.wang], thanks for the comment.

I actually did not think to modify the metrics classes rather than working 
around their current limitations but this is definitely good to consider. We 
are specifically interested in the MutableRate metric here, which is currently 
{{synchronized}} since it requires updating of multiple values atomically. For 
something like MutableCounter a LongAdder would be great, but I am wondering if 
we can make it apply here? I particularly note the Javadoc which says, of 
bq. Because this method is intrinsically racy, it should only be used when it 
is known that no threads are concurrently updating.
But we would need the ability to do resets for MutableRate. I suppose we could 
potentially read lock around a normal increment of a LongAdder and write lock 
upon snapshotting; or, probably more performant, use an AtomicReference to 
store the LongAdder and create a new one when we snapshot rather than 
attempting to reset. Any thoughts on that? 

> Add MutableRate metrics for FSNamesystemLock operations
> -------------------------------------------------------
>                 Key: HDFS-10872
>                 URL: https://issues.apache.org/jira/browse/HDFS-10872
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: namenode
>            Reporter: Erik Krogen
>            Assignee: Erik Krogen
>         Attachments: FSLockPerf.java, HDFS-10872.000.patch, 
> HDFS-10872.001.patch, HDFS-10872.002.patch, HDFS-10872.003.patch, 
> HDFS-10872.004.patch
> Add metrics for FSNamesystemLock operations to see, overall, how long each 
> operation is holding the lock for. Use MutableRate metrics for now. 

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org

Reply via email to