请教：es2.3.4升级es5.5.3出现的问题

Elasticsearch | 作者 yang009ww | 发布于2018年06月01日 | 阅读数：2495

系统提示：这个人太懒了，什么问题描述都没有写！

5 个回复

事项：es2.3.4版本升级到es5.5.3
环境：centos6.5, jdk1.8, 3个集群，每个集群3个节点，每个节点2个cpu24核16g, cms回收机制
问题：1. cpu使用率特别高，达到90%
2. 集群状态为green,会出现分片自动移到其它节点的情况(本来每个节点2个分片，之后会出现1个节点2个分片，1个节点3个分片，1个节点1个分片)
3. 集群状态为green, 会出现节点自动退出又自动加入的情况

说明：1. cpu使用高，发现有大量的慢查询产生，但是此次升级业务未做调整，在2.3.4的版本上也有类似慢查询，但是极少
2. 出现分片移到其它节点时的日志请看图片：

3. 出现节点自动退出集群的日志请看图片：

请各位大神帮忙指点，或者提供一些排查思路，谢谢！
也请M大和wood大抽点时间帮我分析一下，谢谢！

yang009ww

补充一个问题：重启集群分片恢复的特别慢，单个分片5-10G, 一个集群内大概有10个这样的分片，等了一个小时active_shards_percent一直没变过，比如70%，一个小时后还是70%，如图：

每份索引目前是分的3个分片，不是有说法说单分片50G是上限，但是目前不到10G, 离上限还差的比较远，是什么原因可能导致这么慢呢？求大神指点~

yang009ww

继续补充：当重启集群后，集群会先恢复分片，分片恢复完之后集群状态变green, 然后会进行分片平衡。但是发现没过多久，集群状态从green变为yellow, 然后又开始恢复分片，恢复完之后又开始分片平衡，在不到1个小时内，此现象出现了2次，查看日志文件，发现和问题3的日志一样，即：failed to obtain shard lock

medcl - 今晚打老虎。

这个主意是节点反复平衡的问题吧，你这个是升级之后的集群么？看样子是3个节点的集群。
如果是因为业务查询压力造成的慢查询以及大量 GC 把节点拖挂，你应该先优化查询，然后还需要设置节点的再平衡的延迟时间和节点的 ping 超时时间，避免没有意义的再平衡。

kennywu76 - Wood

关于升级以后慢查询的问题，参考 https://elasticsearch.cn/article/446 看一下是否有对数值型字段做term/terms query的。

要回复问题请先登录或注册

请教：es2.3.4升级es5.5.3出现的问题

系统提示：这个人太懒了，什么问题描述都没有写！

5 个回复

发起人

相关问题

问题状态

请教：es2.3.4升级es5.5.3出现的问题

系统提示：这个人太懒了，什么问题描述都没有写！

与内容相关的链接

5 个回复

发起人

相关问题

问题状态