Hive JDBC连接Tez(AM)容器长期不释放问题的解决方法
Hive JDBC连接Tez(AM)容器长期不释放问题的解决方法问题有这样一个问题是很常见的:如果我们的Hive使用默认使用Tez作为执行引擎,当我们使用IDE通过Hive JDBC连接时,会出现在一个很“有趣”的想象:即如果我们不断开这个JDBC连接,则在Yarn上会持续有有一个Tez的AM容器持续存在,只有当端开JDBC连接时,这个容器才会被释放。关于Tez在Yarn的资源布局,可参考这篇..
问题
有这样一个问题是很常见的:如果我们的Hive使用默认使用Tez作为执行引擎,当我们使用IDE通过Hive JDBC连接时,会出现在一个很“有趣”的想象:即如果我们不断开这个JDBC连接,则在Yarn上会持续有有一个Tez的AM容器持续存在,只有当端开JDBC连接时,这个容器才会被释放。关于Tez在Yarn的资源布局,可参考这篇文章:https://zh.hortonworks.com/blog/introducing-tez-sessions/ ,其中一张直观的图如下:
当团队拥有一个资源较为充裕的集群时,这不会是一个问题,并且维持这样一个Tez的AM容器是有好处的,好处就是:避免每次执行SQL时重新初始化容器。当如果我们的集群资源有限,使用的人又较多时,这个问题就会导致一个很糟糕的状况:那就是每个人连接到Hive时就会有一个Tez的AM容器生成,相应的至少有一个cpu core要分配出去,如果总的核数较小,单JDBC连接就会挤占掉所有的资源。(注:实际上,Yarn并不会等到所有的核都被占用,而是当所有AM容器占用的资源达到一定的比例时,就不会再允许新的应用提交了,这个比例的参数项名为:yarn.scheduler.capacity.maximum-am-resource-percent,默认0.2, 即20%)
解决方案
显然,在资源有限的前提下,我们不能让一个session长期存在,只要存在一个session就会有一个core被占用着无法释放,所以我们要让session存在的时间尽可能的短!而控制一个session生命周期长短的参数其实主要是它的超时时间,这个参数是:tez.session.am.dag.submit.timeout.secs
, 在Hive和Tez上都有这个配置,默认值是一个比较大的数值,如果我们想尽可能早的释放掉资源,就把这个值设为0,最为了稳妥,最好是在Tez和Hive上都进行设置!
以HDP为例,Tez设置为:
Hive设置为:
更多推荐
所有评论(0)