[
https://issues.apache.org/jira/browse/HDFS-11586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15954169#comment-15954169
]
Chen Liang commented on HDFS-11586:
-----------------------------------
Thanks [~zshao] for bringing up this.
I want clarify things a bit though. I found "%free" a pretty vague term, could
you please elaborate your point a little bit? For example, if it is
read-locked, it can still have more read lock but no write lock. This is
"read-free" but not "write-free" in that sense. Is the point understanding
"what is the fraction of time where the lock is held by someone in the previous
X period of time" or something else?
Also, what is the expected behaviour of the thread? I was thinking of printing
the lock stats to debug log, but then I think the 10ms you proposed will
probably generate a little bit too many log lines. Were you referring to
something different here?
> Report %free, %write_locked, %read_locked for the NameNode FSNamesystemLock
> ---------------------------------------------------------------------------
>
> Key: HDFS-11586
> URL: https://issues.apache.org/jira/browse/HDFS-11586
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: namenode
> Reporter: Zheng Shao
> Assignee: Chen Liang
> Priority: Minor
>
> It's useful to understand how busy the NameNode is by providing these
> metrics, similar to the %util number from iostat for disks.
> When %free goes to close to 0, we know the NameNode is congested (just like
> when disk %util goes to 100%).
> This can be implemented very cheaply by using a thread that wakes up every
> 10ms to check FSNamesystemLock's getReadLockCount() and isWriteLocked() (via
> the member coarseLock).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
