记一次端口不释放的问题

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源码进行改造的。