概述
昨天线上ETLJob突然挂起,查看Hive Log异常:
[ERROR]:Utils - FAILED: Error in acquiring locks: Locks on the underlying objectscannot be acquired. retry after some time
WARNunexpected error, closing socket connection and attempting reconnectjava.io.IOException: Connection reset by peer
一看是获取锁失败,关于Hive获取锁的流程简析:
http://boylook.blog.51cto.com/7934327/1308139
在看ZK发现从这台Agent到ZK的连接已经超过maxClientCnxns了,立刻先把ZK增加问题得到缓解,然后开始找RC:
出现问题的前一天修改了hive.lock.sleep.between.retries到5s,是不是和这个有关系呢?每次ZKLockManager在retry前会执行prepareretry,主要是检查前一个zk连接是否超时,如果没有继续用这个连接否则new一个zk连接,因此问题不应该是这里.
再看出问题的Client上主要跑了ETL agent和hiveserver2,发现连接都是从hiveserver2上来的,怀疑是不是因为默认的maxWorkerThreads略大了,不过worker和zk的连接无关,只是决定了ThreadPoolExecutor的线程数,看hiveserver部分代码最终与ZK交互的执行层面是OperationHandle,进而就是大家都熟悉的Driver run方法了,到这里基本上才开始进行SQL的解析运行,包括锁的处理.
而我们使用的是CDH4.2.0,这里有一个OperationHandle 资源泄露进而导致到ZK连接泄漏的一个Bug:
https://issues.cloudera.org/browse/DISTRO-512?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel#issue-tabs–> HIVE-4398,在Hive0.11已经修复
update:https://issues.apache.org/jira/browse/HIVE-5853
转载于:https://blog.51cto.com/boylook/1315751
最后
以上就是故意板凳为你收集整理的HiveServer2 ZooKeeper 连接泄漏的全部内容,希望文章能够帮你解决HiveServer2 ZooKeeper 连接泄漏所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复