问题描述
另外一个服务有使用到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本身上,在网上找到了一个遇到类似情况的博客
…好难啊!!!怎么办??还能怎么办,分析一下是不是同样的原因呗。
首先查看服务器资源消耗:
通过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信息时,发现图标查不出来对应的数据。所以现在可以开心的下班啦?明天来了找阿里云的人看一下再说。
今天拿到了线上日志,查看了最近两天重启时间点的日志。看到了两类错误日志。
最主要的报错信息就是下边这个。
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这个问题查的累人啊。太菜了
Hive在每次用的时候去连接,用完之后直接断开连接。