首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Hive调优 | HiveServer2 性能优化与GC优化

Hive调优 | HiveServer2 性能优化与GC优化

作者头像
大数据技术架构
发布2021-12-02 09:41:42
1.4K0
发布2021-12-02 09:41:42
举报

一、问题描述

开发者利用jdbc连接hiveserver2(或者利用jdbc连接 spark HiveThriftServer2,由于两者都是提供jdbc连接到hive,因此,后面都统一称为利用jdbc连接hiveserver2),执行简单查询、复杂分析、超复杂分析等不同的sql任务,session并发量还很高(五六百甚至上千的并发),本质上要求大数据平台同时具备oltp的高并发与olap的高分析能力。对于hiveserver2这一类基于hadoop平台的jdbc server而言,非常不适合这种高并发的应用。

最近发现hiveserver2(本质上是提供jdbc连接的driver进程)经常发生严重卡死故障。而且卡死分成两种现象:

故障现象1:

通过jdbc无法正常连接到hiveserver2;

故障现象2:

能够很顺利通过jdbc连接到hiveserver2,但是无法执行任何sql任务。

每次jdbc连接hiveserver2出现卡死,就必须重启hiveserver2才能解决。无休无止的重启,在生产环境是非常致命的糟糕体验。

二、问题分析

找到hiveserver2卡死的真正原因,才能够彻底解决该问题。经过与公司内熟悉hiveserver2和spark HiveThriftServer2的同事沟通,之前在公司内部环境也经常遇到卡死的情况,定位原因主要是两类:

(1)主要是由于jdbc连接hiveserver2的并发量非常高,而且某些sql任务会严重消耗hiveserver2的内存,导致hiveserver2压力巨大,比如:reducetask获取mapOutputStatus的时候。这种情况是由于hiveserver2自身的复杂压力大,内存损耗严重,严重GC进而导致hiveserver2故障。这种故障对应于上面介绍的“故障现象1”,通过jdbc无法正常连接到hiveserver2。为了解决该故障,可以通过优化内存GC可以缓解hiveserver2的GC卡死问题。

(2)由于执行某个大型sql任务,把资源池资源消耗殆尽,且长时间不释放,导致所有通过hiveserver2提交的sql任务都无法执行。这种故障对应于上面介绍的“故障现象2”,能够很顺利通过jdbc连接到hiveserver2,但是无法执行任何sql任务。为了解决此类故障,只能让开发者减少复杂任务执行,或者将不同类型的任务,提交到不同的资源队列执行。

三、复现问题

3.1 复现jdbc无法连接到hiveserver2故障

根据同事的指导,我们也首先从内存GC角度入手。通过jstat 命令,每隔10秒获取一次hiveserver2进程的GC情况,最终复现该问题。以下是hiveserver2发生卡死,jdbc无法连接到hiveserver2的时候,统计GC的结果:

可以看到,当hiveserver2发生严重卡死时,也就是hiveserver2 进程发生严重GC的时候。因此,可以通过优化hiveserver2的内存GC来优化hiveserver2,使之支持更高的并发、能够执行更复杂的sql任务。

3.2 复现通过hiveserver2提交sql任务无法执行故障

我们通过jdbc连接到hiveserver2,提交三个表之间的join复杂联合查询。三个表的数据量分别在 10亿、5亿和1亿,三个表做join查询。运行结果如下如所示:

可以看到,三个表之间做复杂的关联查询任务,sql执行最终会卡在reduce阶段,一直把资源占据。而后通过hiveserver2提交的其它任务sql任务,都会因为无法获取到资源被卡住无法执行。

这种情况,只能让开发者将大型任务提交到单独的资源队列,防止某个大型任务一直占据资源,使得其它任务无法执行。

四、问题解决

4.1 扩大hiveserver2启动的内存参数

既然出现了严重GC,首先需要做的就是将hiveserver2转移,重新部署到一台CPU和内存资源非常丰富的服务器。我们检测到原来部署hiveserver2的服务器上面还部署了HDFS nemanode、hbase master、zookeeper、yarn resourcemanager,资源严重不足。因此,将hiveserver2迁移到资源非常空闲的另外一台服务器。

4.2 采用优化GC机制和参数

之前hiveserver2进程的启动参数没有添加GC参数,也就是说采用系统默认的GC机制。这一次,我们结合公司内部的使用情况,采用cms GC机制。

同时为了更方便观察GC情况,我们在启动命令里面添加jconsle。具体的参数如下所示:

-Xms49152m 
-Xmx49152m 
-Djava.rmi.server.hostname=xxx.xxx.xxx.xxx 
-Dcom.sun.management.jmxremote.port=8999 
-Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.ssl=false 
-XX:+UseParNewGC 
-XX:ParallelGCThreads=30 
-XX:MaxTenuringThreshold=10 
-XX:TargetSurvivorRatio=70 
-XX:+UseConcMarkSweepGC 
-XX:+CMSConcurrentMTEnabled 
-XX:ParallelCMSThreads=30 
-XX:+UseCMSInitiatingOccupancyOnly 
-XX:+CMSClassUnloadingEnabled 
-XX:+DisableExplicitGC 
-XX:CMSInitiatingOccupancyFraction=70 
-XX:+UseCMSCompactAtFullCollection 
-XX:CMSFullGCsBeforeCompaction=1 
-verbose:gc 
-XX:+PrintGCDetails 
-XX:+PrintGCDateStamps 
-XX:GCLogFileSize=512M 
-Xloggc:/data/log/tbds/spark/gc-sparkthrift.log-${timenow}

其中,有几个参数需要根据服务器的自身资源量来决定。

(1)-Xms49152m -Xmx49152m 这两个参数需要考虑服务器实际的可用内存资源来设定;

(2)-XX:ParallelGCThreads=30 和 -XX:ParallelCMSThreads=30 这两个参数需要考虑服务器实际的CPU核数来决定。切记不要超过CPU核数。

经过上面两种优化方法之后,hiveserver2目前非常稳定。当然基于hadoop平台的hiveserver2本身支持的jdbc并发连接数有限,不可能做到关系型数据库那样的oltp高并发性能。当hiveserver2 的 jdbc session连接数达到极端情况(超过上千的并发),还是可能发生严重GC。此时,需要重启hiveserver2,并且控制并发量。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2021-11-28,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 大数据技术架构 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一、问题描述
  • 二、问题分析
  • 三、复现问题
    • 3.1 复现jdbc无法连接到hiveserver2故障
      • 3.2 复现通过hiveserver2提交sql任务无法执行故障
      • 四、问题解决
        • 4.1 扩大hiveserver2启动的内存参数
          • 4.2 采用优化GC机制和参数
          相关产品与服务
          领券
          问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档