通过Hive执行任务，异常——Hive：Connection refused；Hadoop：too many open files

问题背景：

工作中需要用到Hiveserver提交任务到hadoop进行离线计算，在正常测试运行整个离线计算任务几遍后，在后面提交任务的运行过程中遇到该异常。

问题表现：

从监控模块放回的异常与Hive中日志异常一样，均为如下所示：

2013-03-01 15:14:12 [ERROR] [SummaryReport] [orderNumStatics/订单量] File '/home/hadoop/hive-0.7.1-cdh3u3/lib/py/hive_service/ThriftHive.py', line 87, in recv_execute
raise result.ex
HiveServerException:HiveServerException(errorCode=12, message='Query returned non-zero code: 12, cause: FAILED: Hive Internal Error: java.lang.RuntimeException(java.net.ConnectException: Call to nn/10.28.168.128:41000 failed on connection exception: java.net.ConnectException: Connection refused)', SQLState='42000')

hadoop集群中datanode的日志文件报异常：

DataXceiverServer: IOException due to:java.io.IOException: Too many open files

在后面的测试中进一步得到如下情况：

在遇到该异常后，立即直接通过Hive（非Thrift）提交查询语句，返回同样的错误；等待几分钟后，重新提交Hive语句，可执行成功。继续提交，当达到一定量之后，又返回之前的错误。重新启动hiveserver或hadoop，均可以很好地解决只能执行少量任务的问题。

问题原因：

目前我们应用的hadoop版本hadoop-0.20.2-cdh3u3，其存在一个Bug，编号： HDFS-2028 ——  3.cn/uQ1t4B

Bug 描述如下：

When I load data into tables of hive via hiver cli or hive server, there are always some ESTABLISHED or CLOSE_WAIT status socket connections. And these tcp connections won't be released unless you quit hive or restart hiveserver.

意思是： 当用户通过hive 与 hive server执行hadoop任务时， 系统中会存在一些状体为 ESTABLISHED 与CLOSE_WAIT 的socket连接，而这些tcp连接只有在退出hive，或重启hiveserver服务时才会释放。

通过这个Bug的描述，发现这正是我们当前遇到的问题。

解决方法：

1. 修复上述中的Bug， path 补丁文件 1010-HDFS-1836.-Thousand-of-CLOSE_WAIT-socket.patch， 重新生成hadoop-core-0.20.2-cdh3u3.jar，然后替换掉之前的jar包；

2. 修改hadoop集群节点的/etc/security/limits.conf文件，在文件末尾加入下内容：

* soft nofile 65536
* hard nofile 65536

此操作的含义是修改Linux系统允许打开的最大文件数，其中系统默认的文件打开数为1024，这里修改成65536，根据实际情况设置成相应的值即可。

3. 修改hadoop配置文件 hdfs-site.xml，修改dfs.datanode.max.xcievers属性的值，可根据实际情况设置大一点

<property>

 <name>dfs.datanode.max.xcievers</name>

 <value>4096</value>

</property>

解决效果：

在与hadoop小组同时的沟通过程中得知，解决方法中的步骤一已经实施，但在我们的实际情况中依然会遇到本文中描述的问题。分析原因可能有如下几种：

1. hadoop-0.20.2-cdh3u3的这个bug并未真正修复；

2. hadoop-0.20.2-cdh3u3已修复该bug，而处理这些未及时关闭的链接，采取的方案可能是等待操作关闭，即需要某个设定的时间再关闭。

在实施解决方案中的步骤2、3之后，经过多次测试，没有再遇到本文中提到的问题。继续测试发现未关闭的链接数保持在一定值，呈现上下浮动，并没有一直往上增长，故大胆猜测，执行步骤一未能解决问题的原因很可能是上述的第2点。具体是哪种原因，以及上述原因2中可能的等待时间是多长，本人还在学习当中。