hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mingliang Liu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-10335) Mover$Processor#chooseTarget() always chooses the first matching target storage group
Date Wed, 27 Apr 2016 02:16:12 GMT

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

Mingliang Liu commented on HDFS-10335:

The code is as following:
    boolean chooseTarget(DBlock db, Source source,
        List<StorageType> targetTypes, Matcher matcher) {
      final NetworkTopology cluster = dispatcher.getCluster(); 
      for (StorageType t : targetTypes) {
        for(StorageGroup target : storages.getTargetStorages(t)) {
          if (matcher.match(cluster, source.getDatanodeInfo(),
              target.getDatanodeInfo())) {
            final PendingMove pm = source.addPendingMove(db, target);
            if (pm != null) {
              return true;
      return false;

To address this, we can pick a random matching storage group for the given storage type. One
implementation is to shuffle the candidate target storages before iterating them. Will post
a patch shortly.

> Mover$Processor#chooseTarget() always chooses the first matching target storage group
> -------------------------------------------------------------------------------------
>                 Key: HDFS-10335
>                 URL: https://issues.apache.org/jira/browse/HDFS-10335
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: balancer & mover
>    Affects Versions: 2.8.0
>            Reporter: Mingliang Liu
>            Assignee: Mingliang Liu
>            Priority: Critical
> Currently the {{org.apache.hadoop.hdfs.server.mover.Mover$Processor#chooseTarget()}}
always chooses the first matching target datanode from the candidate list. This may make the
mover schedule a lot of task to a few of the datanodes (first several datanodes of the candidate
list). The overall performance will suffer significantly from this because of the saturated
network/disk usage. Specially, if the {{dfs.datanode.balance.max.concurrent.moves}} is set,
the scheduled move task will be queued on a few of the storage group, regardless of other
available storage groups. We need an algorithm which can distribute the move tasks approximately
even across all the candidate target storage groups.
> Thanks [~szetszwo] for offline discussion.

This message was sent by Atlassian JIRA

View raw message