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

Lukas Majercak edited comment on HDFS-12288 at 8/11/17 9:34 PM:
----------------------------------------------------------------

For {{BlockRecoveryWorker}} I agree, this should be included. But then, so 
should be {{DataNode.DataTransfer}} in my opinion, which is currently only 
represented by {{DataNode.xmitsInProgress}}. Note that this one is not even 
included in the current calculation using {{threadGroup}} afaik.


was (Author: lukmajercak):
For {{BlockRecoveryWorker}} I agree, this should be included. But then, so 
should be {{DataNode.DataTransfer}} in my opinion, which is currently only 
represented by {{DataNode.xmitsInProgress}}.

> Fix DataNode's xceiver count calculation
> ----------------------------------------
>
>                 Key: HDFS-12288
>                 URL: https://issues.apache.org/jira/browse/HDFS-12288
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: datanode, hdfs
>            Reporter: Lukas Majercak
>            Assignee: Lukas Majercak
>         Attachments: HDFS-12288.001.patch, HDFS-12288.002.patch
>
>
> The problem with the ThreadGroup.activeCount() method is that the method is 
> only a very rough estimate, and in reality returns the total number of 
> threads in the thread group as opposed to the threads actually running.
> In some DNs, we saw this to return 50~ for a long time, even though the 
> actual number of DataXceiver threads was next to none.
> This is a big issue as we use the xceiverCount to make decisions on the NN 
> for choosing replication source DN or returning DNs to clients for R/W.
> The plan is to reuse the DataNodeMetrics.dataNodeActiveXceiversCount value 
> which only accounts for actual number of DataXcevier threads currently 
> running and thus represents the load on the DN much better.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to