Hadoop 坑爹的Be Replicated to 0 nodes, instead of 1 异常

有段时间不写博客了，感觉自己懒惰了不少，当然也是不够努力。近一年的时间一直在开发Hadoop基础应用。

  新的项目上线之后发现，有些会员上传资源到我们集群的速度，既然跟我们集群的吞吐量差不多，达到了70M+/s的速度。 在向集群put数据时，抛出了异常：

org.apache.hadoop.ipc.RemoteException: java.io.IOException: File /xxx/xxx/xx could only be replicated to 0 nodes, instead of 1

这样的信息告诉我，集群内部无可用的节点了，因为是在put阶段出现的，直觉告诉我，所有的节点是不是都已经写满数据了？

节点少的情况比较容易观察Hadoop的一些问题，查看dfshealth.jsp页面发现，至少有三台节点可写，但dfsClient put数据仍然抛出无节点可用的异常。

追究源码，NameNode身边的 ReplicationTargetChooser#isGoodTarget方法给出了说明：

// check the communication traffic of the target machine
    if (considerLoad) {
      double avgLoad = 0;
      int size = clusterMap.getNumOfLeaves();
      if (size != 0) {
        avgLoad = (double)fs.getTotalLoad()/size;
      }
      if (node.getXceiverCount() > (2.0 * avgLoad)) {
        logr.debug("Node "+NodeBase.getPath(node)+
                  " is not chosen because the node is too busy");
        return false;
      }
}

  isGoodTarget方法对预选的数据节点做出了终审判决，然而除了磁盘空间可利用外，另外需稳定在一定的压力之下，这里的标准是Datanode中XceiverServer所接受的连接数，我们在使用Hadoop时，这个值很容易被忽略，因为这个值不方便被统计到。上段代码说明当前节点的连接数，不得大于集群所有节点平均连接数的两倍。为了使我的系统尽量独力，我在dfshealth.jsp 页面把每台节点的连接数打印了出来，结果发现正好符合上述代码的判断。



比如ReplicationTargetChooser选择了node13，那么即使node13有大片的空间可写，最终也会被上述代码认为是一个不符合条件的节点。

157 > ((27 + 45 + 44 + 54 + 35 + 50 + 104 + 55 + 73 + 69 + 157 + 146)/12 * 2)

这样的异常，一般解决办法是添加节点，或是在节点允许的情况下，对这段算法进行上调。

评论

3 楼 david.org 2011-11-30  

siguzhishu 写道

HBASE中碰到过 ，修改linux的最大连接数。

这个和linux的最大连接数没关系吧，这个选择策略是Namenode设置的。

2 楼 siguzhishu 2011-07-26  

HBASE中碰到过 ，修改linux的最大连接数。

1 楼 langyu 2011-07-13  

这个问题我前几天也追踪到了，很讨厌呀。集群对于load的计算模型还得需要分析下