身安不如心安,屋宽不如心宽 。

ES数据节点中的某一台突然异常,cpu明显高于其他节点

Elasticsearch | 作者 wangxinrong | 发布于2023年04月03日 | 阅读数:5684

我这边有两三个集群出现了类似的情况,并且没有发现共同点。这些集群是不同业务在用。而且ES版本也不完全相同,1个是7.5.2,另外2个是5.6.3。
 
现象是这样:
1.ES集群没有变更、连接ES的应用也没有变更,从某一天开始,就有一台数据节点cpu开始明显高于其他节点,并且情况越来越严重,直到某一天高峰期cpu直接跑满引发问题。
2.有问题的节点在cpu跑满后,有时持续1-2分钟,有时持续10-20分钟,它又会自己降下来。
3.重启ES服务后,节点才恢复正常,然后平稳运行一段时间,时间不确定,有时是几个月有时一个月不到,又出现同样问题,并且出现的节点随机,不一定是原来那个节点。
 
问题节点各项监控指标都挺正常,我只能从监控上得出如下信息:
1.集群上es业务索引只有一个,分片在各个数据节点上分布均衡,连主、副本的分布都是均衡的。
2.从节点层面的读写qps监控上看,问题节点和其他节点的qps是相同的,不是因为访问量不均衡导致节点cpu变高,而是处理同样的请求时,问题节点cpu使用率要明显更高。
3.问题节点的cpu user time比其他节点高,system time并不高,其他节点一样。应该是ES服务本身有什么异常导致cpu使用率高。
4.问题节点的读写活动线程数要高于其他节点,cpu跑满出现问题时,也是问题节点线程数跑满,读或写队列用满,开始出现拒绝。
5.通过看hot_thread、jstack抓取线程信息,都看不出问题节点和其他节点有什么明显区别。问题节点的jvm内存使用、gc等也和其他节点一样。
 
这是cpu监控,一个是5.6.3版本的集群,一个是7.5.2版本的集群

es5.6_.3_.png


es7.5_.2_.png

 
 
有人遇到过类似的情况吗,是es的bug,或者是什么其他原因吗,有没有什么好的排查思路
 
 
 
已邀请:

charlesfang

赞同来自:

有碰到过ThreadLocal对象引起节点cpu异常问题,跟你监控图很像。
 
ThreadLocal中的ThreadLocalMap中有一个table,大量使用会使得ThreadLocalMap的table中的元素Entry大部分指向为null,使得对象设置或者添加时找位置变得很困难,并且,table中Entry对象是一个弱引用,依赖于jvm gc回收。
 
如果使用了g1gc的话,gc只操作了部分内存区,可能长时间操作不到这个坏的ThreadLocal,需要fullgc才能立即释放。所以,我一般是通过强制执行fullgc后(jmap -histo:live pid),才能把cpu降下来。

ake

赞同来自:

大家好,我也遇到同样问题,区别是我的节点是固定的,一共21节点,3master,18data, 每次问题发生时候,都是其中那3个节点,那三个节点在同一个宿主机上面。目前处理方法就是重启集群,这影响特别大,跪求各路大佬相助!!!https://elasticsearch.cn/quest ... 17641,17642,17650,17654#!answer_17654

要回复问题请先登录注册