ES发生clear FieldData 线程和query线程死锁,导致节点query不可用
Elasticsearch | 作者 pyq371783549 | 发布于2016年06月24日 | 阅读数：7041
环境配置信息如下：
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，导致整个应用不可用,几乎无响应。
2.后发现有一个节点的search thread指标和其他节点有差异。
有问题节点search thread线程的信息，queue达到10000,rejected持续增长
3.在某个时间点jboss的timeout异常消失，正常es节点请求问题节点发生org.elasticsearch.common.util.concurrent.EsRejectedExecutionException: rejected execution (queue capacity 10000) on org.elasticsearch.transport.netty.MessageChannelHandler$RequestHandler@702e6b9b
4.随后使用jstack对问题节点thread做snapshot，发现问题节点的线程存在问题。
jstack search线程(100个search线程全是此stack)：
kopf plugin 获取的hot thread：
clear field data线程：
正常节点线程：无clear filed data线程存在，search线程状态如下图：
5.查看问题线程源码：
search getForField code:
clear field data code:
综合以上分析：
thread pool线程一直被clear线程 lock,得不到释放。超过search thread pool的线程进入queue等待，最终timeout。thread queue达到上限后，之后的请求被直接拒绝。应用恢复正常处理(问题节点的数据不能被检索)。
根本原因：
至今不清楚产生死锁的根本原因在哪,为什么clear线程一直处于running状态,lock得不到释放？希望遇到过此问题的大拿能指点一二。
备注：filed data比较小，不存在field data过大的情况。
集群已经运行一年多，第一次发生此问题。且没有重现。
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，导致整个应用不可用,几乎无响应。
2.后发现有一个节点的search thread指标和其他节点有差异。
有问题节点search thread线程的信息，queue达到10000,rejected持续增长
3.在某个时间点jboss的timeout异常消失，正常es节点请求问题节点发生org.elasticsearch.common.util.concurrent.EsRejectedExecutionException: rejected execution (queue capacity 10000) on org.elasticsearch.transport.netty.MessageChannelHandler$RequestHandler@702e6b9b
4.随后使用jstack对问题节点thread做snapshot，发现问题节点的线程存在问题。
jstack search线程(100个search线程全是此stack)：
kopf plugin 获取的hot thread：
clear field data线程：
正常节点线程：无clear filed data线程存在，search线程状态如下图：
5.查看问题线程源码：
search getForField code:
clear field data code:
综合以上分析：
thread pool线程一直被clear线程 lock,得不到释放。超过search thread pool的线程进入queue等待，最终timeout。thread queue达到上限后，之后的请求被直接拒绝。应用恢复正常处理(问题节点的数据不能被检索)。
根本原因：
至今不清楚产生死锁的根本原因在哪,为什么clear线程一直处于running状态,lock得不到释放？希望遇到过此问题的大拿能指点一二。
备注：filed data比较小，不存在field data过大的情况。
集群已经运行一年多，第一次发生此问题。且没有重现。
9 个回复
expone - 80后
赞同来自: pyq371783549
这个问题比较严重了，需要重视下。
qiaol2016 - 80后IT男
赞同来自:
MarkES
赞同来自:
pyq371783549 - 80后IT男!
赞同来自:
daizw8888 - IT男
赞同来自:
kl - 90后IT新贵
赞同来自:
flowaters
赞同来自:
niroy
赞同来自:
"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