hadoop异常:Be Replicated to 0 nodes, instead of 1

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

  新的项目上线之后发现,有些会员上传资源到我们集群的速度,既然跟我们集群的吞吐量差不多,达到了70M+/s的速度。 在向集群put数据时,抛出了异常:
Java代码  收藏代码
  1. 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方法给出了说明: 
Java代码  收藏代码
  1. // check the communication traffic of the target machine  
  2.     if (considerLoad) {  
  3.       double avgLoad = 0;  
  4.       int size = clusterMap.getNumOfLeaves();  
  5.       if (size != 0) {  
  6.         avgLoad = (double)fs.getTotalLoad()/size;  
  7.       }  
  8.       if (node.getXceiverCount() > (2.0 * avgLoad)) {  
  9.         logr.debug("Node "+NodeBase.getPath(node)+  
  10.                   " is not chosen because the node is too busy");  
  11.         return false;  
  12.       }  
  13. }  

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

 

比如ReplicationTargetChooser选择了node13,那么即使node13有大片的空间可写,最终也会被上述代码认为是一个不符合条件的节点。 
Java代码  收藏代码
  1. 157 > ((27 + 45 + 44 + 54 + 35 + 50 + 104 + 55 + 73 + 69 + 157 + 146)/12 * 2)  

这样的异常,一般解决办法是添加节点,或是在节点允许的情况下,对这段算法进行上调。 
posted @ 2014-05-10 23:26  JerryShao  阅读(314)  评论(0编辑  收藏  举报