[ https://issues.apache.org/jira/browse/HDFS-5757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ming Ma updated HDFS-5757: -------------------------- Resolution: Duplicate Status: Resolved (was: Patch Available) This optimization has been taken care of by HDFS-7411. > refreshNodes with many nodes at the same time could slow down NN > ---------------------------------------------------------------- > > Key: HDFS-5757 > URL: https://issues.apache.org/jira/browse/HDFS-5757 > Project: Hadoop HDFS > Issue Type: Improvement > Components: namenode > Reporter: Ming Ma > Assignee: Ming Ma > Attachments: HDFS-5757.patch > > > Sometimes we need to decomm a whole rack of nodes at the same time. When the > decomm is in process; NN is slow. > The reason is when DecommissionManager checks the decomm status, it acquires > namesystem's writer lock and iterates through all DNs; for each DN that is in > decommissioning state, it check if replication is done for all the blocks on > the machine via blockManager.isReplicationInProgress; for large cluster; the > number of blocks on the machine could be big. > The fix could be to have DecommissionManager check for several > decomm-in-progress nodes each time it aquires namesystem's writer lock. -- This message was sent by Atlassian JIRA (v6.3.4#6332)