Hive 使用陷阱（Lock table） 排查过程

为什么80%的码农都做不了架构师？>>>   

前言

业务部门使用python通过hive thrift api做数据统计，早段时间发现在频繁创建表的时候，接口会卡死。经过一番的排查，是因为hive的lock table manager特性对于hive server的接口服务不兼容，解决办法：1）取消lock table manager特性，实际在hive server上lock table也没有作用。 2）使用hive server 2，这个是cloudera公司开发的玩意，但是暂时hive server 2没有提供跨语言的thrift，所以以前的python代码无法使用了。 在我们的环境中还是需要使用python，所以就直接把lock table manager取消了。下面说说排查过程。

排查过程

1.查看业务python程序的日志，lock上了

HiveServerException: HiveServerException(errorCode=10, message='Query returned non-zero code: 10, cause: FAILED: Error in acquiring locks: Locks on the underlying objects cannot be acquired. retry after some time', SQLState='42000')

2.查看hive server的日志,和zookeeper服务建立不了连接了

2013-08-08 10:51:28,196 WARN  zookeeper.ClientCnxn (ClientCnxn.java:run(1089)) - Session 0x0 for server dn241.kis.hadoop.cn/172.28.29.241:2181, unexpected error, closing socket connection and attempting reconnect

3.查看一下zookeeper服务器日志,提示已经到达zookeeper允许的最大连接了

2013-08-08 12:25:16,647 [myid:2] - WARN  [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@193] - Too many connections from /172.28.26.83 - max is 50

4.那回到hive server看是否都是它说创建的连接

#查看一下hive server的pid号，这里是2744

ps axu |grep hive

#查看一下hive server建立的连接数，果然与zookeeper都建立了50个连接

lsof -p 2744 |grep -i tcp |grep dn240 |wc -l

50

lsof -p 2744 |grep -i tcp |grep dn241 |wc -l 

50

5.那确定了问题，如何改善呢。增加zookeeper允许的单IP最大连接数

修改zookeeper配置文件(/etc/zookeeper/conf/zoo.cfg)

maxClientCnxns=200

minSessionTimeout=1000

maxSessionTimeout=60000

6.确实zookeeper的连接到达200了，但是问题是每次跑完hive查询，hive server与zookeeper的连接都不会释放，那连接数只会一直的累加，调大连接数不是解决根本的方法

7.查看相关文档，发现hive server 与 hive server 2的区别是，hive server 2是提供并发连接，而lock table manager也是为了处理并发的。那在我们的应用中每次查询都是创建一个实例去做，只有一个连接，那这个特性对于我们的应用来说是没有用的。那我把特性给取消了，注释了以下配置文件,并重启hive server

  hive.support.concurrency
  Enable Hive's Table Lock Manager Service
  true


  hive.zookeeper.quorum
  Zookeeper quorum used by Hive's Table Lock Manager
  dn240.kis.hadoop.cn,dn241.kis.hadoop.cn

8.取消后，业务正常运行，且hive server不再与zookeeper建立连接，问题解决。

转载于:https://my.oschina.net/kisops/blog/151968