ES发生clear FieldData 线程和query线程死锁,导致节点query不可用

Elasticsearch | 作者 pyq371783549 | 发布于2016年06月24日 | 阅读数:4400

环境配置信息如下:
data节点:16个,虚拟机(Red Hat Enterprise Linux Server release 6.3 (Santiago))、16C/32G。
jdk:1.7.0_60   es:1.7.0
 
 
问题现象:
1.es上层应用出现连接ES timeout,导致整个应用不可用,几乎无响应。
jbosslog.png

 
2.后发现有一个节点的search thread指标和其他节点有差异。
有问题节点search thread线程的信息,queue达到10000,rejected持续增长
aa.png

 
3.在某个时间点jboss的timeout异常消失,正常es节点请求问题节点发生org.elasticsearch.common.util.concurrent.EsRejectedExecutionException: rejected execution (queue capacity 10000) on org.elasticsearch.transport.netty.MessageChannelHandler$RequestHandler@702e6b9b
eslog.png

 
4.随后使用jstack对问题节点thread做snapshot,发现问题节点的线程存在问题。
jstack search线程(100个search线程全是此stack):
thread1.png


kopf plugin 获取的hot thread:
thread3.png

 
clear field data线程:
thread2.png

 
 
正常节点线程:无clear filed data线程存在,search线程状态如下图:
thread4.png

 
5.查看问题线程源码:
search getForField code:
code1.png

 
clear field data code:
code2.png

code3.png

 
 
综合以上分析:
thread pool线程一直被clear线程 lock,得不到释放。超过search thread pool的线程进入queue等待,最终timeout。thread queue达到上限后,之后的请求被直接拒绝。应用恢复正常处理(问题节点的数据不能被检索)。
 
 
根本原因:
至今不清楚产生死锁的根本原因在哪,为什么clear线程一直处于running状态,lock得不到释放?希望遇到过此问题的大拿能指点一二。
备注:filed data比较小,不存在field data过大的情况。
   集群已经运行一年多,第一次发生此问题。且没有重现。

 
 
 
 
已邀请:

expone - 80后

赞同来自: pyq371783549

导致整个应用不可用,几乎无响应.
这个问题比较严重了,需要重视下。

qiaol2016 - 80后IT男

赞同来自:

MarkES

赞同来自:

这个问题看起来ES还是不稳定啊

pyq371783549 - 80后IT男!

赞同来自:

此问题是个雷,有可能随时爆炸!

daizw8888 - IT男

赞同来自:

这个问题要关注!

kl - 90后IT新贵

赞同来自:

这个问题,遇见过多次,环境 windows10+jdk8,查询的时候就是假死,然后控制台ctrl+c后恢复正常!不得其解

flowaters

赞同来自:

1.7比较老了,尽快升级到2.x吧

niroy

赞同来自:

2.4版本出现了类似的问题,在运行一段时间后,有 c2 complier线程一直得不到释放,导致cpu被抢占。

"C1 CompilerThread3" #9 daemon prio=9 os_prio=0 tid=0x00007fe35c040000 nid=0x360 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
   Locked ownable synchronizers:
- None
"C2 CompilerThread2" #8 daemon prio=9 os_prio=0 tid=0x00007fe35c03e000 nid=0x35f runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
   Locked ownable synchronizers:
- None
目前还不知道如何分析

PK采纳哦

赞同来自:

这个问题 我们遇到了,
原因:  2.0以下版本
IndexFieldDataService 的
private final Map<String, IndexFieldDataCache> fieldDataCaches = ConcurrentCollections.newConcurrentMap();; // no need for concurrency support, always used under lock
存在bug
注意 楼主截的第5图, getforfield,当多个线程同时加载field,会概率导致hashmap无限死循环.
 
解决方案:
需要升级至2.0以上版本或者 将 fieldDataCaches改成线程安全的currenthashmap
 
 
 
 
 

要回复问题请先登录注册