调用Hive，服务周期性Down掉

问题描述

  另外一个服务有使用到Hive，读取打点信息，第一次出现问题是4月20号开始的，每天早晨六点服务准时Down掉…莫名崩溃，

第一次的解决方法

具体看了一下Hive数据库连接的配置

druid:
  type: com.alibaba.druid.pool.DruidDataSource
  hive:
    url: jdbc:hive2://domain:port/shuangshi_dh
    driver-class-name: org.apache.hive.jdbc.HiveDriver
    user: **
    password: **
    initialSize: 5
    minIdle: 5
    maxActive: 20
    maxWait: 6000
    timeBetweenEvictionRunsMillis: 60000
    minEvictableIdleTimeMillis: 300000
    validationQuery: select 'x'
    testWhileIdle: true
    testOnBorrow: false
    testOnReturn: false
    poolPreparedStatements: true
    maxPoolPreparedStatementPerConnectionSize: 20

testOnBorrow=false ： 表明不检查连接池中连接的可用性，如果连接池中的连接被数据库关掉了，通过连接池getConnection方法就会获取到这些不可用的连接，致使获取数据time out。而且这些连接不会被清除掉，所以服务器端就会有大量的不可用连接，服务器最终Down掉。
  但是如果设置testOnBorrow=true 服务器的性能消耗又会非常大。因此经查阅资料后，在数据库配置中增加连接回收机制:

removeAbandonedTimeout: 300
removeAbandoned: true

removeAbandonedTimout :泄露的连接可以被删除的超时值
removeAbandoned :标记是否删除泄露的连接.这个属性设置为true的时候，可以清除超过了removeAbandonedTimout时间限制的连接。

这样设置就可以把没用的连接清除掉，防止出现time out的情况了。

• 分析的贼好，贼经典…

要不是五一假期的最后一天，线上服务又Down掉了，我就相信了自己的分析??

---

---

第二次出现问题

  出现的还是那个时间，还是那个地点，出现的让人猝不及防…差一点点以为是我的女朋友准时在家里等着我。

这次又出现了一样的问题，好好看看把~这回把目标主要定在Hive本身上，在网上找到了一个遇到类似情况的博客

https://blog.csdn.net/xin_jmail/article/details/85004967

…好难啊！！！怎么办？？还能怎么办，分析一下是不是同样的原因呗。
首先查看服务器资源消耗：

通过top命令可以看到第一个进程cpu和内存占用是最多的。因此通过 top -Hp pid 命令查看一下这个进程中所有线程占的资源.

可以看到460个线程，都处于Sleeping状态～窃喜，好像是发现了问题了.

通过 jstack -l pid 把堆栈信息导出来。

"task-281" #1203 prio=5 os_prio=0 tid=0x00007fd93c2f8800 nid=0x7be5 waiting on condition [0x00007fd8ee59f000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000000c6946560> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

   Locked ownable synchronizers:
	- None

导出的堆栈信息几乎所有都是这样的!!哇！！是不是就是因为线程一直处于waiting状态，使得服务器遭不住了，就挂掉了？？

Too young too simple.Native!!! 小伙子，你差错方向了?(心里一万个…)

出现这样堆栈信息，是因为服务Down掉之后，服务里边的线程没有被及时的kill掉，这个是服务挂掉的结果，而不是原因～还得换个方向…

  去阿里云的E-MapReduce平台看了一下Hive服务器的数据图标，仔细研读了图标中的各个指标(因为真的是看不懂啊…),发现cpu，内存等数据并没有异常，要查看Thread信息时，发现图标查不出来对应的数据。所以现在可以开心的下班啦?明天来了找阿里云的人看一下再说。

---

---

2019-05-07

今天拿到了线上日志，查看了最近两天重启时间点的日志。看到了两类错误日志。

最主要的报错信息就是下边这个。

org.springframework.jdbc.CannotGetJdbcConnectionException: Failed to obtain JDBC Connection; nested exception is com.alibaba.druid.pool.GetConnectionTimeoutException: wait millis 6000, active 1, maxActive 20, creating 1

另外一个报错日志如下。

报错信息如下：

org.springframework.dao.DataAccessResourceFailureException: ConnectionCallback; ]; java.net.SocketException: Broken pipe (Write failed); nested exception is java.sql.SQLException: java.net.SocketException: Broken pipe (Write failed)

这两个问题查资料都是指向了druid框架，因为有连接未关闭一直在占有，还是需要更详细的看一下是连接在什么地方一直占有着连接。因此在配置文件中增加一项配置。

logAbandoned: true # 关闭abanded连接时输出错误日志

所以加完这一项配置之后，druid配置变成了如下：

druid:
  type: com.alibaba.druid.pool.DruidDataSource
  hive:
    url: jdbc:hive2://domain:port/shuangshi_dh
    driver-class-name: org.apache.hive.jdbc.HiveDriver
    user: **
    password: **
    initialSize: 5
    minIdle: 5
    maxActive: 20
    maxWait: 6000
    timeBetweenEvictionRunsMillis: 60000
    minEvictableIdleTimeMillis: 300000
    validationQuery: select 'x'
    testWhileIdle: true
    testOnBorrow: false
    testOnReturn: false
    poolPreparedStatements: true
    maxPoolPreparedStatementPerConnectionSize: 20
    removeAbandonedTimeout: 300
    removeAbandoned: true
    logAbandoned: true

发到了测试，明天看一下日志输出再看是啥问题…^T这个问题查的累人啊。太菜了

---

---

2019-05-14   这个问题，最后模糊定位是Hive自身的连接池满了，所以外部服务在进行健康检查的时候，获取不到可用的连接，检查超时，服务下线。 最后定了一个方法：

Hive在每次用的时候去连接，用完之后直接断开连接。