[
https://issues.apache.org/jira/browse/HDFS-16070?focusedWorklogId=611792&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-611792
]
ASF GitHub Bot logged work on HDFS-16070:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 16/Jun/21 07:59
Start Date: 16/Jun/21 07:59
Worklog Time Spent: 10m
Work Description: zhengchenyu commented on a change in pull request #3105:
URL: https://github.com/apache/hadoop/pull/3105#discussion_r652445254
##########
File path:
hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/datanode/DataNode.java
##########
@@ -2646,6 +2655,7 @@ public void run() {
} catch (Throwable t) {
LOG.error("Failed to transfer block {}", b, t);
} finally {
+ transferringBlock.remove(b);
Review comment:
I don't catch you advice, transferringBlock.add and
transferringBlock.remove could be only called DataTransfer.run, I think won't
leave garbage.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 611792)
Time Spent: 3h 10m (was: 3h)
> DataTransfer block storm when datanode's io is busy.
> ----------------------------------------------------
>
> Key: HDFS-16070
> URL: https://issues.apache.org/jira/browse/HDFS-16070
> Project: Hadoop HDFS
> Issue Type: Improvement
> Affects Versions: 3.3.0, 3.2.1
> Reporter: zhengchenyu
> Priority: Major
> Labels: pull-request-available
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> When I speed up the decommission, I found that some datanode's io is busy,
> then I found host's load is very high, and ten thousands data transfer thread
> are running.
> Then I find log like below.
> {code}
> # setup datatranfer log
> 2021-06-08 13:42:37,620 INFO org.apache.hadoop.hdfs.server.datanode.DataNode:
> DatanodeRegistration(10.201.4.49:9866,
> datanodeUuid=6c55b7cb-f8ef-445b-9cca-d82b5b077ed1, infoPort=9864,
> infoSecurePort=0, ipcPort=9867,
> storageInfo=lv=-57;cid=CID-37e80bd5-733a-4d7b-ba3d-b46269573c72;nsid=215490653;c=1584525570797)
> Starting thread to transfer
> BP-852924019-10.201.1.32-1584525570797:blk_-9223372036449848858_30963611 to
> 10.201.7.52:9866
> 2021-06-08 13:52:36,345 INFO org.apache.hadoop.hdfs.server.datanode.DataNode:
> DatanodeRegistration(10.201.4.49:9866,
> datanodeUuid=6c55b7cb-f8ef-445b-9cca-d82b5b077ed1, infoPort=9864,
> infoSecurePort=0, ipcPort=9867,
> storageInfo=lv=-57;cid=CID-37e80bd5-733a-4d7b-ba3d-b46269573c72;nsid=215490653;c=1584525570797)
> Starting thread to transfer
> BP-852924019-10.201.1.32-1584525570797:blk_-9223372036449848858_30963611 to
> 10.201.7.31:9866
> 2021-06-08 14:02:37,197 INFO org.apache.hadoop.hdfs.server.datanode.DataNode:
> DatanodeRegistration(10.201.4.49:9866,
> datanodeUuid=6c55b7cb-f8ef-445b-9cca-d82b5b077ed1, infoPort=9864,
> infoSecurePort=0, ipcPort=9867,
> storageInfo=lv=-57;cid=CID-37e80bd5-733a-4d7b-ba3d-b46269573c72;nsid=215490653;c=1584525570797)
> Starting thread to transfer
> BP-852924019-10.201.1.32-1584525570797:blk_-9223372036449848858_30963611 to
> 10.201.16.50:9866
> # datatranfer done log
> 2021-06-08 13:54:08,134 INFO org.apache.hadoop.hdfs.server.datanode.DataNode:
> DataTransfer, at bd-tz1-hadoop-004049.zeus.lianjia.com:9866: Transmitted
> BP-852924019-10.201.1.32-1584525570797:blk_-9223372036449848858_30963611
> (numBytes=7457424) to /10.201.7.52:9866
> 2021-06-08 14:10:47,170 INFO org.apache.hadoop.hdfs.server.datanode.DataNode:
> DataTransfer, at bd-tz1-hadoop-004049.zeus.lianjia.com:9866: Transmitted
> BP-852924019-10.201.1.32-1584525570797:blk_-9223372036449848858_30963611
> (numBytes=7457424) to /10.201.16.50:9866
> {code}
> You will see last datatranfser thread was done on 13:54:08, but next
> datatranfser was start at 13:52:36.
> If datatranfser was not done in 10min(pending timeout + check interval), then
> next datatranfser for same block will be running. Then disk and network are
> heavy.
> Note: decommission ec block will trigger this problem easily, becuase every
> ec internal block are unique.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]