1 背景
一台服务器的端口数是有限的资源，如果端口被大量占用则会存在未知的故障。
案例：
线上HiveServer2发生故障: 大量任务hang住, 经排查是因为服务器没有可用的端口分配造成的。
进一步排查发现，存在大量状态为CLOSE_WAIT的50010端口连接。
而50010端口是DN的，由此推断应该是存在流未关闭的情况。
2 定位
2.1 查看当前端口数量使用情况
~]$netstat -tanp | grep "CLOSE_WAIT" | wc -l
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
43957
2.2 查看大量链接都是哪个进程的
~]$ netstat -tanp | grep "CLOSE_WAIT" | awk '{print $NF}' | awk -F'/' '{print $1}' | sort | uniq -c
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
22476 63459
21484 63523
看下是什么进程：
~]$ ps -ef | grep 63459
hadoop 5796 96249 0 17:21 pts/0 00:00:00 grep --color=auto 63459
hadoop 63459 1 99 Mar04 ? 39-01:46:41 /usr/local/jdk1.8.0_77//bin/java ...(省略) hive-service-1.2.1-325.jar org.apache.hive.service.server.HiveServer2
~]$ ps -ef |grep 63523
hadoop 5979 96249 0 17:21 pts/0 00:00:00 grep --color=auto 63523
hadoop 63523 1 99 Mar04 ? 41-10:04:18 /usr/local/jdk1.8.0_77//bin/java...（省略）hive-service-1.2.1-325.jar org.apache.hive.service.server.HiveServer2
可以看出是HiveServer2进程。
2.3 查看都是什么连接
看下HiveServer2进程都是什么连接：
~]$ netstat -tanp | grep "CLOSE_WAIT" | grep -E '63459|63523' | awk '{print $5}' | awk -F':' '{print $1,$NF}' | sort | uniq -c | sort -nk1
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
1 10.11.11.11 38673
...
10703 10.11.11.12 50010
10716 10.11.11.13 50010
10803 10.11.11.14 50010
50010端口连接有多少呢？
~]$ netstat -tanp | grep 50010 | wc -l
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
43973
可以看出是大量的50010端口连接， 50010是DN的端口，由此可见存在访问DN但未释放连接的情况。
2.4 根因分析
2.4.1 是否是Hive引擎自身bug ？
首先，如果Hive引擎自身bug，这个问题早就应该暴露出来。
其次，Hive引擎连接泄漏的bug已经修过好多了，尤其是FileSystem相关的，所以可能性不大。
最后，我们查阅了社区相关issue，没有相关问题。
由于Hive提供了开放的UDF接口，从经验判断不规范的UDF也是有可能导致这个问题的。
2.4.2 实锤定位UDF
我们抓取当前日志加载的UDF函数包：
~]$ grep "Added resources" hive.log | awk '{print $NF}' | sort | uniq -c
经分析抓取嫌疑最大的UDF并反编译用户UDF包发现，用户代码逻辑存在读取hdfs文件的情况，且读取文件后，未关闭流。
至此真想大白。
3 反思
Hive提供了特别开放的UDF接口，用户可以自定义UDF实现任何你想到的逻辑（包括System.exists(1), 曾出现过用户在UDF中调用System.exists(1)导致HiveServer2服务进程退出的情况），开放的同时带来了很大的安全隐患，尤其是采用HS2集中式服务的环境来说。
为保障服务的稳定性，我们做了这么几件事：
- 1）做服务器端口使用情况的监控
- 2）HS2在UDF中禁用System.exists
- 3）在集中式HS2服务中，自定义UDF的发布需要有严格的代码审查流程。
其中，第二点是需要对Hive源码进行改造的。