`
david.org
  • 浏览: 157810 次
  • 性别: Icon_minigender_1
  • 来自: 上海
社区版块
存档分类
最新评论

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)

这样的异常,一般解决办法是添加节点,或是在节点允许的情况下,对这段算法进行上调。
  • 大小: 50.3 KB
分享到:
评论
3 楼 david.org 2011-11-30  
siguzhishu 写道
HBASE中碰到过 ,修改linux的最大连接数。


这个和linux的最大连接数没关系吧,这个选择策略是Namenode设置的。
2 楼 siguzhishu 2011-07-26  
HBASE中碰到过 ,修改linux的最大连接数。
1 楼 langyu 2011-07-13  
这个问题我前几天也追踪到了,很讨厌呀。集群对于load的计算模型还得需要分析下

相关推荐

Global site tag (gtag.js) - Google Analytics