调用Hive，服务周期性Down掉

问题描述

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

第一次的解决方法

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

druid:
  type: com.alibaba.druid.pool.DruidDataSource
  hive:
    url: jdbc:hive2://172.17.0.104:10000/shuangshi_dh
    driver-class-name: org.apache.hive.jdbc.HiveDriver
    user: anything
    password: anything
    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.****.net/xin_jmail/article/details/85004967

…好难啊！！！怎么办？？还能怎么办，分析一下是不是同样的原因呗。
首先查看服务器资源消耗：
调用Hive，服务周期性Down掉
通过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信息时，发现图标查不出来对应的数据。所以现在可以开心的下班啦????明天来了找阿里云的人看一下再说。

调用Hive，服务周期性Down掉

问题描述

第一次的解决方法

第二次出现问题

相关推荐