一、问题描述
开发者利用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，并且控制并发量。
若有收获，就点个赞吧
0 人点赞
