Parquet-library-fatal-error

parquet-Hadoop 1.9.0 大量close-wait问题。

一个开源基础库引发的严重产品事故,整个事件场内block超过4小时以上。

我们某服务部署上线,界面化的DAG任务,主要跑机器学习全流程作业,运行一段时间,发现后端数据平台查询、预览数据功能全部不可用,导致大量上游业务系统block住。

报错关键信息:

  1. UnknowHostException
1
java.net.UnknownHostException: node199mm1002

排查Hadoop集群平台是否正常,如上主机是否可到达,发现均正常,集群无问题。

  1. Too many open files
1
2
java.net.SocketException: Too many open files; Host Details: local host is : "java.net.UnknownHostException: tserver-98989-bmhtk: tserver-98989-bmhtk: System error": destination host is: "node199mm1002":25000; 
at org.apache.hadoop.net.NetUtils.wrapException(NetUtils.java:776)

操作系统,根据ulimit -a查看系统fd配置,主机fd上限为640000,tserver容器的fd上限为65536。通过kubectl进入tserver容器,使用命令“watch ‘ss | grep CLOSE-WAIT | wc -l’”查看,发现65278个close-wait,快崩了。

close wait

基本可确定是大量,close-wait连接泄漏问题,对连接泄漏列表进一步分析:

1
2
3
ss | grep CLOSE-WAIT > close_wait.txt
cat close_wait.txt| grep CLOSE_WAIT | grep 50010|wc -l
cat close_wait.txt| grep CLOSE_WAIT | grep http|wc -l

发现两个特征,一个是属于http相关相关close-wait,占比2%,剩余的全是连接50010端口出现的close-wait,查询Hadoop相关端口,发现50010是DataNode的数据转发端口,初步怀疑是代码连接Hadoop DataNode查询数据没有关闭流导致。

  1. DataManager Service:listFiles error IOException

排查DataManager Service相关代码,发现listFiles函数,主要功能,读取HDFS获取某个目录下的parquet集合,然后进行读取parquet的meta信息,前端进行展示大小,行数,还会读取任意问题进行预览,或者随机预览数据。
并未发现有任何异常情况,系统每次调用此接方法导致阻塞,一步步跟进调试,发现已经进入parquet相关的代码。

经过认证检查每一行代码,发现流相关操作均进行了关闭,并没有任何问题。

验证思考:缩小问题范围,对listFiles函数,调用的全部方法进行最小化单元测试,最终在开发环境preview方法中,实现了连接HDFS读取parquet文件,使用rest接口,单独调用此方法,每次调用close-wait都会增加2,并且长期存在。

监控命令“watch ‘ss | grep CLOSE-WAIT | wc -l’”,疯狂访问,一直增加不曾下降。

猜测是Parquet依赖库,有连接泄漏问题,于是向社区求助,我们引入的parquet 1.9.0上下几个版本的commit以及bugfix全看了一遍,重点关注close stream相关。

PR PARQUET-783 提到相关问题:

···
This PR addresses https://issues.apache.org/jira/browse/PARQUET-783.

ParquetFileReader opens a SeekableInputStream to read a footer. In the process, it opens a new FSDataInputStream and wraps it. However, H2SeekableInputStream does not override the close method. Therefore, when ParquetFileReader closes it, the underlying FSDataInputStream is not closed. As a result, these stale connections can exhaust a clusters’ data nodes’ connection resources and lead to mysterious HDFS read failures in HDFS clients, e.g.

org.apache.hadoop.hdfs.BlockMissingException: Could not obtain block: BP-905337612-172.16.70.103-1444328960665:blk_1720536852_646811517
···

根据社区,反馈:

1
downgrade parquet to 1.8.2 to fix 1.9.0 connection leaks

降级parquet库版本为1.8.2修复此问题,升级最新版本也是能解决问题,不过部分接口大动,导致不兼容,经过考虑决定降级库,而不该任何代码解决问题。

修复代码 by https://github.com/apache/parquet-mr/pull/388/files

1
2
3
4
@Override
public void close() throws IOException {
stream.close();
}

总结

整个过程,由于全部服务容器化部署,导致排查问题周期比较长,获取日志还是比较原始的命令行方式,门槛较高,由于在现场发现问题,不能及时进行问题的追溯,只能根据只言片语的反馈进行问题追踪。如果不是在开发环境,复现此问题,整个问题排查起来异常困难,开始思考是否有tracking工具,可以快速定位问题。代码的最小化单元测试,只能定位范围,最终一直无法确定是某个函数直接导致的问题,代码编写中函数功能单一性拆分是一门学问。

期间,重启大发又一次发挥了奇效。在开发环境复现问题,并修复bug,patch修复各个产品线的不同版本。

如果,你还在用有连接泄漏问题的Parque版本,快快升级吧。

Whoami公众号

原创文章,转载请注明: 转载自Itweet的博客
本博客的文章集合: http://www.itweet.cn/archives/