dfs.datanode.max.xcievers&dfs.datanode.max.transfer.threads介绍

前言：

         这篇文章主要是介绍这个参数是什么意思，他的作用和估值的参考方法。（参考自：http://blog.cloudera.com/blog/2012/03/hbase-hadoop-xceivers/）

         (dfs.datanode.max.xcievers和dfs.datanode.max.transfer.threads都是指的一个参数不过前者是hdp1.0的叫法)

dfs.datanode.max.xcievers设置得过低有什么后果？

                       首先概括的说这个参数是表示datanode上负责进行文件操作的线程数。如果需要处理的文件过多，而这个参数设置得过低就会有一部分文件

处理不过来，就会报下面这个异常：

ERROR org.apache.hadoop.dfs.DataNode: DatanodeRegistration(10.10.10.53:50010,storageID=DS-1570581820-10.10.10.53-50010-1224117842339,infoPort=50075, ipcPort=50020):DataXceiver: java.io.IOException: xceiverCount 258 exceeds the limit of concurrent xcievers 256

我们都知道linux系统中所有的文件操作都被绑定到一个socket上，那么形象点解释，操作文件就是对这个socket操作，进一步具体可以把他看做是一个线程。而这个参数就是指定这种线程的个数。

比如：

public DFSInputStream open(String src) throws IOException public FSDataOutputStream create(Path f) throws IOException

在dfs中的这种open(),create()的操作对应到真实的动作就是在服务端（dn）new一个线程（socket）来处理。

下面来看看这个线程机制是怎么运转的：

        在datanode里面有一个专门的线程组来维护这些线程，同时有一个守护线程来监视这个线程组的体量——DataXceiverServer

        它负责监测线程数量是否到达上线，超过就抛出异常：

//在datanode启动时，创建这个线程组 this.threadGroup = new ThreadGroup(“dataXceiverServer”); this.dataXceiverServer = new Daemon(threadGroup, new DataXceiverServer(ss, conf, this)); this.threadGroup.setDaemon(true); // auto destroy when empty   //DataXceiverServer随时监控及报警 /** Number of concurrent xceivers per node. */ int getXceiverCount() { return threadGroup == null ? 0 : threadGroup.activeCount(); }   if (curXceiverCount > dataXceiverServer.maxXceiverCount) { throw new IOException(“xceiverCount ” + curXceiverCount + ” exceeds the limit of concurrent xcievers “ + dataXceiverServer.maxXceiverCount); }

为什么会有这样的机制呢？

       这是因为如果这样的线程过多，系统内存就会暴掉（一个线程约占1M内存，一台datanode以60G内存计，则最多允许有6万个线程，而这只是理想状态的）

一些估算dfs.datanode.max.xcievers值得方法：

       最常规的算法：

                             

       主要用作Hbase的服务器：

              

               （Reserve(20%)是指多分配20%的空间以允许文件数等的增长）