HiveServer2 频繁宕机根本原因分析

原创 已于 2022-02-22 11:02:13 修改 · 4.7k 阅读 · 17 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#hadoop #hive

于 2022-02-22 10:59:58 首次发布
本文深入分析了HiveServer2在凌晨因内存泄漏导致的宕机问题，通过jstat与heapdump发现内存占用持续增长直至OOM，确认为HiveServer本身内存管理问题。探讨了不解决或版本升级的应对策略。

文章目录

概要

问题描述： hiveServer2跑一段时间后, 一般在凌晨就会宕机（凌晨有很多定时任务），宕机比较有规律，就是跑几天就宕一次，分析一下原因。作业没有特别大的任务。
分析方法：jstat, dump
分析结论：hive2的hiveServer本身内存泄漏造成
解决方法：不解决或升级。

一、进行heap dump

1.1 查HiveServer2的进程id，得到219045

root@tbds-10-232-2-37:/data/var> ps -ef|grep HiveServer2
hive     219045      1 92 Feb17 ?        3-13:55:08 /usr/jdk64/jdk1.8.0_111/bin/java -Xmx16384m -Dhdp.version=2.2.0.0-2041 -Djava.net.preferIPv4Stack=true -Dhdp.version=2.2.0.0-2041 -Dhadoop.log.dir=/data/var/log/hadoop/hive -Dhadoop.log.file=hadoop.log -Dhadoop.home.dir=/data/bigdata/tbds/usr/hdp/2.2.0.0-2041/hadoop -Dhadoop.id.str=hive -Dhadoop.root.logger=INFO,console -Djava.library.path=:/usr/hdp/current/hadoop-client/lib/native/Linux-amd64-64:/data/bigdata/tbds/usr/hdp/2.2.0.0-2041/hadoop/lib/native -Dhadoop.policy.file=hadoop-policy.xml -Djava.net.preferIPv4Stack=true -Xmx16384m -Djava.security.auth.login.config=/etc/hive/conf.server/kafka_client_for_ranger_jaas.conf -XX:+UseG1GC -XX:InitiatingHeapOccupancyPercent=70 -XX:+PrintGCDateStamps -XX:GCLogFileSize=512M -verbose:gc -XX:+PrintGCDetails -Xloggc:/data/var/log/hive/hive_gc.log -Dlog4j.configurationFile=/etc/hive/conf/hive-log4j2.xml -Dhadoop.security.logger=INFO,NullAppender org.apache.hadoop.util.RunJar /usr/hdp/2.2.0.0-2041/hive/lib/hive-service-2.2.0.jar org.apache.hive.service.server.HiveServer2 --hiveconf hive.aux.jars.path=file:///usr/hdp/current/hive-webhcat/share/hcatalog/hive-hcatalog-core-2.2.0.jar,file:///usr/hdp/current/hive-webhcat/share/hcatalog/hive-hcatalog-core.jar,file:///usr/hdp/current/hive-webhcat/share/hcatalog/hive-hcatalog-pig-adapter-2.2.0.jar,file:///usr/hdp/current/hive-webhcat/share/hcatalog/hive-hcatalog-pig-adapter.jar,file:///usr/hdp/current/hive-webhcat/share/hcatalog/hive-hcatalog-server-extensions-2.2.0.jar,file:///usr/hdp/current/hive-webhcat/share/hcatalog/hive-hcatalog-server-extensions.jar,file:///usr/hdp/current/hive-webhcat/share/hcatalog/hive-hcatalog-streaming-2.2.0.jar,file:///usr/hdp/current/hive-webhcat/share/hcatalog/hive-hcatalog-streaming.jar -hiveconf hive.metastore.uris=

1.2 根据进程号，查jstat的gc信息

root@tbds-10-x-xx-x:/data/var>jstat -gcutil 219045 2000
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT   
  0.00   0.00   0.00  88.12  73.03  36.52  14741 3097.156     3   94.687 3191.843
  0.00   0.00   0.00  88.12  73.03  36.52  14741 3097.156     3   94.687 3191.843
  0.00   0.00   0.00  88.12  73.03  36.52  14741 3097.156     3   94.687 3191.843
  0.00   0.00   0.00  88.12  73.03  36.52  14741 3097.156     3   94.687 3191.843

在这里插入图片描述

发现fullGC后，老年代，还是很满(FullGC的次数由2变到3)。

在这里插入图片描述
艰难的fullGC,
经过28s的fullGC，顺利完成gc,但老年代92.19%，按照目前趋势 应该明天凌晨就跑挂，看看预言成真不。。。

在这里插入图片描述

二、heap dump分析

2.1 把hiveServer2的heap dump回来

经过FullGC后进行的heap dump.
-dump:live 只要存活的对象

hive@tbds-x-x-x-x:/data/var/hiveDump>jmap -dump:live,format=b,file=/data/var/hiveDump/hiveserver2.afterFgc.dump.bin 219045
Dumping heap to /data/var/hiveDump/hiveserver2.dump.bin ...
Heap dump file created

dump回来，发现文件大小17G。

2.2 使用eclipse memory analyzer进行分析

修改EMA的MemoryAnalyzer.ini，把Xmx改为28G, -Xmx28672m.(我的电脑32G)

2.3 leak suspects

发现问题：
问题1： 7627个org.apache.hadoop.hive.ql.exec.UDFClassLoader 占用4.1G内存
问题2：16585个log4jd的RandomAccessFile占用 4.1G内存
问题3：java.util.jar.JarFile占用2.9G
这三个对象把都实例放到HashMap上进行缓存，导致实例永远在FullGC时都可达，导致无法进行回收。

在这里插入图片描述
在这里插入图片描述

Shallow 与 Retained的区别
Shallow Size
Shallow Size是对象本身占据的内存的大小，不包含其引用的对象。对于常规对象（非数组）的Shallow Size由其成员变量的数量和类型来定，而数组的ShallowSize由数组类型和数组长度来决定，它为数组元素大小的总和。

Retained Size
Retained Size=当前对象大小+当前对象可直接或间接引用到的对象的大小总和。(间接引用的含义：A->B->C,C就是间接引用) ，并且排除被GC Roots直接或者间接引用的对象

换句话说，Retained Size就是当前对象被GC后，从Heap上总共能释放掉的内存。
不过，释放的时候还要排除被GC Roots直接或间接引用的对象。他们暂时不会被被当做Garbage。

最大的retain heap
请添加图片描述

有busy monitor thread
请添加图片描述

请添加图片描述

2.4 dominatorTree对象占用空间比例

下图中，大的对象，无法回收
第一个MedatadataProvider一看就是里面用了享元模式（缓存），数据是无法回收的。其他系统类无法回收，最后的UDFClassLoader占用589k，看上去不大，但有7627个（2.3的问题1中分析出这个数字）。7627个*589k/1024/1024=4.28G。恐怖，全部无法回收。

请添加图片描述

2.5 整个jstat后台脚本，记录gc情况

脚本

root@tbds-x-x-x-37:/data/var>s nohup jstat -gcutil 219045 2000 > /data/var/hiveserver.gcutil.20220221.log 2>&1 &

第二天上班，发现的确凌晨挂了。
挂前的jstat信息：

  S0     S1       E     O      M     CCS    YGC     YGCT    FGC    FGCT     GCT   
  0.00   0.00   0.00  99.99  71.97  35.45  21507 5736.954   547 16373.339 22110.293
  0.00   0.00  62.14  99.99  71.97  35.45  21508 5736.954   547 16403.868 22140.822
  0.00   0.00   0.00  99.99  71.99  35.46  21510 5738.118   548 16403.868 22141.986
  0.00   0.00   0.00  99.99  71.99  35.46  21510 5738.118   548 16403.868 22141.986
  0.00   0.00   0.00  99.99  71.99  35.46  21510 5738.118   548 16403.868 22141.986
  0.00   0.00   0.00  99.99  71.99  35.46  21510 5738.118   548 16403.868 22141.986
  0.00   0.00   0.00  99.99  71.99  35.46  21510 5738.118   548 16403.868 22141.986
  0.00   0.00   0.00  99.99  71.99  35.46  21510 5738.118   548 16403.868 22141.986
  0.00   0.00   0.00  99.99  71.99  35.46  21510 5738.118   548 16403.868 22141.986
  0.00   0.00   0.00  99.99  71.99  35.46  21510 5738.118   548 16403.868 22141.986
  0.00   0.00   0.00  99.99  71.99  35.46  21510 5738.118   548 16403.868 22141.986
  0.00   0.00   0.00  99.99  71.99  35.46  21510 5738.118   548 16403.868 22141.986
  0.00   0.00   0.00  99.99  71.99  35.46  21510 5738.118   548 16403.868 22141.986
  0.00   0.00   0.00  99.99  71.99  35.46  21510 5738.118   548 16403.868 22141.986
  0.00   0.00   0.00  99.99  71.99  35.46  21510 5738.118   548 16403.868 22141.986
  0.00   0.00   0.00  99.99  71.99  35.46  21510 5738.118   548 16403.868 22141.986
  0.00   0.00   0.00  99.99  71.99  35.46  21510 5738.118   548 16403.868 22141.986
  0.00   0.00   0.00  99.99  71.99  35.46  21510 5738.118   548 16403.868 22141.986
  0.00   0.00  61.76 100.00  71.97  35.46  21511 5738.118   548 16436.419 22174.538
  0.00   0.00   0.00 100.00  71.98  35.46  21516 5740.012   548 16436.419 22176.431
  0.00   0.00   0.00 100.00  71.98  35.46  21517 5740.730   549 16436.419 22177.149
  0.00   0.00   0.00 100.00  71.98  35.46  21517 5740.730   549 16436.419 22177.149
  0.00   0.00   0.00 100.00  71.98  35.46  21517 5740.730   549 16436.419 22177.149
  0.00   0.00   0.00 100.00  71.98  35.46  21517 5740.730   549 16436.419 22177.149
  0.00   0.00   0.00 100.00  71.98  35.46  21517 5740.730   549 16436.419 22177.149
  0.00   0.00   0.00 100.00  71.98  35.46  21517 5740.730   549 16436.419 22177.149
  0.00   0.00   0.00 100.00  71.98  35.46  21517 5740.730   549 16436.419 22177.149
  0.00   0.00   0.00 100.00  71.98  35.46  21517 5740.730   549 16436.419 22177.149
  0.00   0.00   0.00 100.00  71.98  35.46  21517 5740.730   549 16436.419 22177.149
  0.00   0.00   0.00 100.00  71.98  35.46  21517 5740.730   549 16436.419 22177.149
  0.00   0.00   0.00 100.00  71.98  35.46  21517 5740.730   549 16436.419 22177.149
  0.00   0.00   0.00 100.00  71.98  35.46  21517 5740.730   549 16436.419 22177.149
  0.00   0.00   0.00 100.00  71.98  35.46  21517 5740.730   549 16436.419 22177.149
  0.00   0.00   0.00 100.00  71.98  35.46  21517 5740.730   549 16436.419 22177.149
  0.00   0.00   0.00 100.00  71.98  35.46  21517 5740.730   549 16436.419 22177.149
  0.00   0.00   0.00  99.98  71.98  35.46  21518 5741.179   550 16466.653 22207.833
  0.00   0.00   0.00  99.98  71.98  35.46  21518 5741.179   550 16466.653 22207.833
  0.00   0.00   0.00  99.98  71.98  35.46  21518 5741.179   550 16466.653 22207.833
  0.00   0.00   0.00  99.98  71.98  35.46  21518 5741.179   550 16466.653 22207.833
  0.00   0.00   0.00  99.98  71.98  35.46  21518 5741.179   550 16466.653 22207.833
  0.00   0.00   0.00  99.98  71.98  35.46  21518 5741.179   550 16466.653 22207.833
  0.00   0.00   0.00  99.98  71.98  35.46  21518 5741.179   550 16466.653 22207.833
  0.00   0.00   0.00  99.98  71.98  35.46  21518 5741.179   550 16466.653 22207.833
  0.00   0.00   0.00  99.98  71.98  35.46  21518 5741.179   550 16466.653 22207.833
  0.00   0.00   0.00  99.98  71.98  35.46  21518 5741.179   550 16466.653 22207.833
  0.00   0.00   0.00  99.98  71.98  35.46  21518 5741.179   550 16466.653 22207.833
  0.00   0.00   0.00  99.98  71.98  35.46  21518 5741.179   550 16466.653 22207.833
  0.00   0.00   0.00  99.98  71.98  35.46  21518 5741.179   550 16466.653 22207.833
  0.00   0.00   0.00  99.98  71.98  35.46  21518 5741.179   550 16466.653 22207.833
  0.00   0.00   0.00  99.98  71.98  35.46  21518 5741.179   550 16466.653 22207.833
  0.00   0.00  62.00  99.98  71.98  35.46  21519 5741.179   550 16496.641 22237.821
  0.00   0.00   0.00  99.98  71.98  35.46  21520 5741.951   551 16496.641 22238.592
  0.00   0.00   0.00  99.98  71.98  35.46  21520 5741.951   551 16496.641 22238.592
  0.00   0.00   0.00  99.98  71.98  35.46  21520 5741.951   551 16496.641 22238.592
  0.00   0.00   0.00  99.98  71.98  35.46  21520 5741.951   551 16496.641 22238.592
  0.00   0.00   0.00  99.98  71.98  35.46  21520 5741.951   551 16496.641 22238.592
  0.00   0.00   0.00  99.98  71.98  35.46  21520 5741.951   551 16496.641 22238.592
  0.00   0.00   0.00  99.98  71.98  35.46  21520 5741.951   551 16496.641 22238.592
  0.00   0.00   0.00  99.98  71.98  35.46  21520 5741.951   551 16496.641 22238.592
  0.00   0.00   0.00  99.98  71.98  35.46  21520 5741.951   551 16496.641 22238.592
  0.00   0.00   0.00  99.98  71.98  35.46  21520 5741.951   551 16496.641 22238.592
  0.00   0.00   0.00  99.98  71.98  35.46  21520 5741.951   551 16496.641 22238.592
  0.00   0.00   0.00  99.98  71.98  35.46  21520 5741.951   551 16496.641 22238.592
  0.00   0.00   0.00  99.98  71.98  35.46  21520 5741.951   551 16496.641 22238.592
  0.00   0.00   0.00  99.98  71.98  35.46  21520 5741.951   551 16496.641 22238.592
  0.00   0.00   0.00  99.98  71.98  35.46  21520 5741.951   551 16496.641 22238.592
  0.00   0.00   0.00  99.98  71.99  35.46  21524 5742.970   551 16526.578 22269.549
  0.00   0.00   0.00  99.98  71.99  35.46  21527 5744.093   552 16526.578 22270.672
  0.00   0.00   0.00  99.98  71.99  35.46  21527 5744.093   552 16526.578 22270.672
  0.00   0.00   0.00  99.98  71.99  35.46  21527 5744.093   552 16526.578 22270.672
  0.00   0.00   0.00  99.98  71.99  35.46  21527 5744.093   552 16526.578 22270.672
  0.00   0.00   0.00  99.98  71.99  35.46  21527 5744.093   552 16526.578 22270.672
  0.00   0.00   0.00  99.98  71.99  35.46  21527 5744.093   552 16526.578 22270.672
  0.00   0.00   0.00  99.98  71.99  35.46  21527 5744.093   552 16526.578 22270.672
  0.00   0.00   0.00  99.98  71.99  35.46  21527 5744.093   552 16526.578 22270.672
  0.00   0.00   0.00  99.98  71.99  35.46  21527 5744.093   552 16526.578 22270.672
  0.00   0.00   0.00  99.98  71.99  35.46  21527 5744.093   552 16526.578 22270.672
  0.00   0.00   0.00  99.98  71.99  35.46  21527 5744.093   552 16526.578 22270.672
  0.00   0.00   0.00  99.98  71.99  35.46  21527 5744.093   552 16526.578
最低0.47元/天 解锁文章
Impala中的高可用性设计：如何确保系统的可靠性和高可用性？
AI天才研究院
07-15 2116
作者：禅与计算机程序设计艺术 随着大数据、云计算、容器化、微服务等新兴技术的快速发展，越来越多的企业把数据库从单机上迁移到分布式集群中进行运行。由于分布式系统环境复杂、系统规模庞大，因此对其系统可用性要求也越来越高。而Impala作为开源分布式查询引擎，正在成为众多大数据平台的重要组成部分。为了保证Impala在真实业务场景中的高可用性，
Hive中跑MapReduce Job出现OOM问题分析及解决
热门推荐
OopsOutOfMemory盛利的博客
11-21 2万+
一、引子今天在跑一段很复杂而且涉及数据量10年的N个表join的长SQL时，发生了OOM的异常。由于一个map通常配置只有64MB或者128MB，则在Map阶段出现OOM的情况很少见。所以一般发生在reduce阶段。但是今天这个异常详细的看后，会发现既不是map阶段，也不是reduce阶段，发现不是执行过程，而是driver提交job阶段就OOM了。Hive中XMLEncoder序列化Mapred
HiveServer2频繁宕机 - Hive踩坑记录
大数据研究小白
08-04 1749
在跑定时任务一段时间后，会出现管道断开的错误日志，并且Hs2的10000端口宕机。
合并文件解决HiveServer2内存溢出方案
IT晓白
06-06 1351
使用HiveServer2查询数据时，会将元数据都加载到内存中，如果一个表格的分区很大，每个分区中又有很多的小文件，就会导致将元数据加载到内存中时使用的内存比较大。因此，Cloudera公司推荐使用的分区数最好不要超过1000个分区；同时分区中的也不要存储过多的为小文件，要定期对数据进行治理以合并小文件。
Hadoop Hdfs Edit log 加载错误，重启无效问题解决过程
flyinf_guo的专栏
12-20 2753
cdh 问题，启动显示正常，但是不能通过hdfs连接。 版本 ：5.13 问题：hdfs 启动错误，提示下面日志 2021-12-20 00:14:56,817 WARN org.apache.hadoop.hdfs.server.namenode.FSNamesystem: Only one image storage directory (dfs.namenode.name.dir) configured. Beware of data loss due to lack of redundant sto
hiveserver2经常挂断的原因
qq_43688472的博客
09-04 2649
配置问题：不正确的配置可能导致 HiveServer2 发生问题。如果资源不足，可能会导致 HiveServer2 挂断。Hive 版本问题：某些 Hive 版本可能存在已知的问题或 bug，可能会导致 HiveServer2 挂断。确保使用的 Hive 版本是稳定的，最好是已修复了已知问题的最新版本。查询问题：某些查询可能会占用大量资源或导致错误，从而导致 HiveServer2 崩溃。并发连接数量过多：如果 HiveServer2 处理大量并发连接，可能会超过其容量限制，导致崩溃或挂断。
hiveserver2经常挂掉
Radiation_x的博客
03-31 3295
一般是默认堆空间过小导致的 将hive(根路径下)/conf/hive-env.xml文件里增加一行配置更改堆大小为512mb或者以上
HiveServer2运行慢，不定时宕机，问题排查
spark_dev的博客
01-28 3382
HiveServer2运行慢，不定时宕机，问题排查 文章目录HiveServer2运行慢，不定时宕机，问题排查1. 问题描述2. 原因分析（分析方法）3. 解决方案总结 1. 问题描述 大数据组件 HiveServer2性能问题，有时运行很慢，几天宕机一次，需要不定时重启。 2. 原因分析（分析方法） 分析思路： 运行慢时，jstat 查看 gc回收情况 root@tbds-1:~>ps -ef|grep HiveServer2 hive 137791 1 99 Jan
大数据-案例-离线数仓-在线教育：MySQL(业务数据)-ETL(Sqoop)-＞Hive数仓【ODS层-数据清洗-＞DW层(DWD-统计分析-＞DWS)】-导出(Sqoop)-＞MySQL-＞可视化
u013250861的博客
07-13 2430
一、访问咨询主题看板 1. 需求分析 目的: 分析每一个调研需求需要计算什么指标, 以及计算这个指标需要通过那些维度,而且还包括计算这个需求涉及 到那些表和那些字段 需求1: 统计指定时间段内，访问客户的总数量。能够下钻到小时数据 指标: 访问量 维度: 时间维度: 年 季度 月 天 小时 涉及到哪些表: web_chat_ems_2019_12 涉及到哪些字段: 时间维度: create_time 说明: 发现create_time字段中包含有年 月 天 小时
【CDH】CDH集群hiveserver2服务频繁挂掉
Mrerlou的博客
05-27 1752
问题现象： cdh集群 master00节点 hiveserver2服务2小时内挂掉2次，报内存溢出的问题。 错误日志如下： 问题排查： 打印一下堆的gc 信息 jstat -gc pid 1000 5 堆设置了4g的内存，Eden区只有400M, s0 和 s1区 更小，然后剩余的空间都是老年代区，空间配置不合理，重新配置下堆空间。 解决方案： 设置hiveserver2的jvm参数 -Xmn2g -XX:NewRatio=4 -XX:MaxPermSize=512M -XX:+UseParNew
hiveserver2总是无故挂掉
m0_74903429的博客
12-01 2017
原因；一般情况下是默认堆空间过小导致 解决措施：将hive(根路径下)/conf/hive-env.xml（也可以是hive-env.sh.template)文件里增加一行配置更改堆大小为512mb或者以上
Hiveserver2服务宕机及解决
Realoyou的博客
05-05 3871
描述： 公司内部使用Hue作为数分团队对大数据的分析产出工具，随着数分业务增加和使用人员复杂，不规范SQL，不规范的使用，导致Hue连接Hive的Hiveserver2服务意外宕机，查看服务日志，并无明显报错，只能在CDH管理界面看出是OOM导致的意外退出，想着通过加大内存以及加上万能重启方式，然而并不能解决，服务运行一段时间后，仍然因OOM挂机，因日志没有详细错误信息，只能看到服务在退出时dump出了很大的堆快照文件（-XX:+HeapDumpOnOutOfMemoryError）,分析快照文件相对较为.
hiveserver2掉线修复
weixin_39037208的博客
12-09 2208
使用hive发现hiveserver2有时会挂掉，查看hive.log发现里边没有相关信息， 但在启动hiveserver2的目录下还有一个nohup.out文件，这里边保存有运行信息，打开发现是因为 这种情况是出现在运行了一个错误的查询之后，可以重启或者将值稍微调大一点。 ...
HiveServer2 Service Crashes(hiveServer2 服务崩溃)
cclovezbf的博客
10-07 2187
Troubleshooting Hive | 5.9.x | Cloudera Documentation1.hive分区表太多(这里没有说具体数量。)2.并发连接太多，我记的以前默认是200个连接 3.复杂的hive查询访问表的的分区4.hs2实例数太少如果存在这些情况中的任何一种，Hive可能运行缓慢，或者可能崩溃，因为整个HS2堆内存已满。1.hs2服务直接挂掉，或者你开启新会话失败。2.hs2服务看起来是好的，但是你连接被拒绝3.查询提交重复失败4.查询一直在提交，查询时间长这里太长了，我直接用我自
通过 GC工具分析 HiveServer2停顿时间过长问题
Daphnis的博客
04-01 3527
1.现象 线上环境 HiveServer2报：在前 5分钟内暂停所花的平均时间过长 hs2角色日志如下： 2.分析 看到上面的报错和日志，第一个直觉就是 hs2 GC出问题了，于是使用 jstat命令进行分析： jstat -gcutil 82775 5000 5 这里先简单介绍一下 jstat这条命令： ​ -gcutil，打印 gc统计信息 ​ 82775，java进程ID ​ 5000，5000ms ​ 5，5次 所以这条命令的含义为：每间隔 5000ms打印一次 进程 82775的 gc
记录一次因内存不足而导致hiveserver2和namenode进程宕机的排查
Lv的程序人生
11-22 1095
如果你发现运行了一段时间的进程突然不见了，那可能是内核嫉妒生恨把它给干掉了查询内存溢出被杀掉的进程可以直接通过系统日志来查 grep “Out of memory” /var/log/messages也可以通过专门的命令查找 dmesg -T | grep “Out of memory”
Hive server2慢启动问题排查与解决
Deegue
06-17 6324
1、问题描述 在Hive升级到2.3.6版本后，启动Hive server2需要花费15分钟左右的时间，这对于平时调试和紧急重启影响很大。因此查看启动log，发现两处疑点： 发现主要耗时就在这两处，第一次6分多钟第二次刚好5分钟。 2、问题排查 不多不少的5分钟让我想到了配置metastore连接的超时时间（hive.metastore.client.socket.timeout）刚好也是300s，于是去看这部分代码，并增加了些日志来排查。 org/apache/hadoop/hive/metastore
hiveserver2长时间运行卡顿解决
Burgess_Lee的博客
04-04 3028
主要是转载，觉得很有价值和意义，但是不至于重新来一遍。具体详见链接。 https://blog.youkuaiyun.com/mnasd/article/details/82690414?utm_source=blogxgwz8
解决云服务商hiveserver2服务不稳定的问题
草小诚的博客
03-07 2231
系统对hive
hive的metastore放在pgsql，如果访问超时会不会让hive进程挂掉
最新发布
11-14
<think> 嗯，用户这次的问题很具体，是关于Hive Metastore使用PostgreSQL作为后端时，连接超时是否会导致Hive进程挂掉。看来用户遇到了生产环境中的稳定性问题，需要明确的技术判断。 从引用[1]提到的生产环境问题来看，用户可能正在经历Metastore相关的性能瓶颈。引用[3]展示了元数据访问的完整链条：Hive客户端→Metastore服务→关系数据库(HMS)→HDFS，其中PostgreSQL就是HMS的存储层。这里的关键在于区分“超时”和“崩溃”的区别。 根据引用[4]的高可用方案，真正的Hive进程挂掉需要同时满足两个条件：一是连接超时后客户端重试机制耗尽（hive.metastore.failure.retries参数），二是没有配置Metastore高可用。引用[5]提到maxSize参数控制数据库连接数，如果连接泄漏确实可能引发雪崩效应。 用户没有明确说是否配置了高可用，所以需要分情况说明。引用[2]的metatool修复命令提示用户可能已经遇到元数据不一致的情况，这往往是连接问题的前兆。值得提醒用户检查PostgreSQL的max_connections配置是否足够，这个细节在引用[5]的“数据库过载”部分有暗示。 考虑到用户连续询问Metastore问题，应该补充数据库层超时的具体日志特征（如PSQLException），这样用户能更快定位问题。引用[1]提到的“Lock wait timeout”在PostgreSQL中表现为行锁竞争，这和MySQL的行为不同，需要单独说明。 最后生成的相关问题要聚焦在PostgreSQL场景：连接池配置建议、死锁处理、WAL日志分析等，这些都是用户后续可能需要的。特别要加入vacuum维护的提醒，因为PostgreSQL的MVCC机制在频繁DDL时容易引发元数据查询性能下降。 </think> Hive Metastore 使用 PostgreSQL 作为后端数据库时，访问超时**通常不会直接导致 Hive 进程（如 HiveServer2 或 CLI）挂掉**，但会引发严重故障，具体影响如下： --- ### 一、超时的核心影响 1. **Hive 客户端/作业阻塞或失败** - Hive 客户端（如 Beeline）或提交的作业（MapReduce/Spark）在访问 Metastore 超时后： - **重试机制**：客户端会根据配置（如 `hive.metastore.failure.retries`[^5]）尝试重连。 - **超时阈值触发失败**：若重试后仍超时，作业会抛出异常（如 `MetaException`），导致**查询失败**，但**Hive 进程本身不会崩溃**。 - 典型报错： ```plaintext FAILED: HiveException java.lang.RuntimeException: Unable to instantiate org.apache.hadoop.hive.ql.metadata.SessionHiveMetaStoreClient ``` 2. **Metastore 服务稳定性受损** - PostgreSQL 连接超时可能因以下原因加剧问题： - **连接池耗尽**：若超时导致连接未释放，连接池（如 `c3p0.maxSize`[^5]）耗尽后，新请求将被阻塞。 - **线程阻塞**：Metastore Server 处理线程因等待数据库响应而卡死，表现为服务**无响应**（但进程仍在运行）。 3. **级联故障风险** - 若 Metastore 因超时长时间无响应： - **HiveServer2 拒绝请求**：客户端可能收到 `Connection refused` 错误。 - **资源耗尽**：持续超时可能导致 Metastore 进程内存溢出（OOM）[^1]，最终**进程崩溃**。 --- ### 二、关键配置与缓解措施 1. **超时控制参数** 在 `hive-site.xml` 中优化： ```xml <!-- Metastore 客户端超时 --> <property> <name>hive.metastore.client.socket.timeout</name> <value>60</value> <!-- 单位：秒 --> </property> <!-- 数据库连接池最大等待时间 --> <property> <name>hive.metastore.connection.pool.max.wait.millis</name> <value>30000</value> <!-- 单位：毫秒 --> </property> ``` 2. **PostgreSQL 优化** - **连接池配置**：限制最大连接数，避免过载（`c3p0.maxSize`）[^5]。 - **查询优化**：对 Metastore 高频查询表（如 `TBLS`, `PARTITIONS`）建立索引。 - **网络稳定性**：确保 PostgreSQL 与 Metastore 间低延迟网络。 3. **高可用部署**（根本性方案） - **Metastore 高可用**：部署多个 Metastore 实例，通过负载均衡（如 HAProxy）分发请求[^4]。 - **PostgreSQL 高可用**：采用主从复制+自动故障转移（如 Patroni），避免单点故障[^4]。 --- ### 三、典型故障场景与解决方案 | **场景** | **现象** | **解决方案** | |-----------------------------------|------------------------------|------------------------------------------| | PostgreSQL 响应慢 | 作业卡在 “Compiling Query” 阶段[^1] | 优化 PostgreSQL 慢查询，增加连接超时阈值 | | Metastore 连接池耗尽 | 日志报 “Timeout waiting for connection”[^1] | 调整 `c3p0.maxSize` 和 `idle.timeout`[^5] | | PostgreSQL 宕机 | 所有依赖 Metastore 的服务不可用 | 启用数据库高可用 + Metastore 客户端重试 | --- ### 结论 - **直接挂掉？** ❌ Hive 进程（HiveServer2/Metastore）通常不会因单次超时崩溃，但可能因资源耗尽（OOM）或持续阻塞最终停止响应。 - **如何避免？** **核心方案**： 1. 配置合理的超时和重试参数 2. 部署 Metastore 和 PostgreSQL 高可用集群[^4] 3. 监控数据库性能与连接池状态[^5] ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值