一台服务器的端口数是有限的资源,如果端口被大量占用则会存在未知的故障。线上HiveServer2发生故障: 大量任务hang住, 经排查是因为服务器没有可用的端口分配造成的…
1 背景
一台服务器的端口数是有限的资源,如果端口被大量占用则会存在未知的故障。
案例:
线上HiveServer2发生故障: 大量任务hang住, 经排查是因为服务器没有可用的端口分配造成的。
进一步排查发现,存在大量状态为CLOSE_WAIT
的50010
端口连接。
而50010
端口是DN的,由此推断应该是存在流未关闭的情况。
2 定位
2.1 查看当前端口数量使用情况
1 | netstat -tanp | grep "CLOSE_WAIT" | wc -l |
2.2 查看大量链接都是哪个进程的
1 | netstat -tanp | grep "CLOSE_WAIT" | awk '{print $NF}' | awk -F'/' '{print $1}' | sort | uniq -c |
看下是什么进程:
1 | ps -ef | grep 63459 |
可以看出是HiveServer2进程。
2.3 查看都是什么连接
看下HiveServer2进程都是什么连接:
1 | netstat -tanp | grep "CLOSE_WAIT" | grep -E '63459|63523' | awk '{print $5}' | awk -F':' '{print $1,$NF}' | sort | uniq -c | sort -nk1 |
50010端口连接有多少呢?
1 | netstat -tanp | grep 50010 | wc -l |
可以看出是大量的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函数包:
1 | 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源码进行改造的。
本文链接: https://stefanxiepj.github.io/archives/58d895e2.html
版权声明: 本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。转载请注明出处!
![知识共享许可协议](https://i.creativecommons.org/l/by-nc-sa/4.0/88x31.png)