[
https://issues.apache.org/jira/browse/HDFS-10798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15886094#comment-15886094
]
Erik Krogen commented on HDFS-10798:
------------------------------------
My understanding of the intuition for why they would be different is that a
long read lock hold is less serious than a long write lock hold, since other
reads can still proceed. Also long reads may be more expected given listStatus
and contentSummary type commands. It is also typical to have a higher
percentage of operations be read, so potential spam volume may be heavier for
read locks rather than write locks.
That being said, 5000ms may still be a more sensible default, erring on the
side of lower overhead unless an operator actually uses these log statements in
which case they can tune the threshold themselves. [~zhz], do you have any
opinion?
> Make the threshold of reporting FSNamesystem lock contention configurable
> -------------------------------------------------------------------------
>
> Key: HDFS-10798
> URL: https://issues.apache.org/jira/browse/HDFS-10798
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: logging, namenode
> Reporter: Zhe Zhang
> Assignee: Erik Krogen
> Labels: newbie
> Fix For: 2.8.0, 2.7.4, 3.0.0-alpha1
>
> Attachments: HDFS-10789.001.patch, HDFS-10789.002.patch
>
>
> Currently {{FSNamesystem#WRITELOCK_REPORTING_THRESHOLD}} is set at 1 second.
> In a busy system a lower overhead might be desired. In other scenarios, more
> aggressive reporting might be desired. We should make the threshold
> configurable.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
