The requested URL was not found on this server. 不管你信不信,反正我是没找到

elasticsearch集群gc过于频繁,导致集群容易崩溃

Elasticsearch | 作者 yang009ww | 发布于2017年07月25日 | 阅读数:18709

版本:2.3.4
集群情况:6个节点  3个节点分配26G内存,3个节点16G
      共50个indices 770shards 1.5亿docs 400GB+
优化过的措施:
threadpool.search.type: fixed
threadpool.search.size: 100
threadpool.search.queue_size: 5000

indices.fielddata.cache.size: 40%

discovery.zen.fd.ping_timeout: 120s
discovery.zen.fd.ping_retries: 3
discovery.zen.fd.ping_interval: 30s

index.refresh_interval: 60s
transport.tcp.compress: true
bootstrap.mlockall: true
 
问题:最近es集群总是会挂掉,查看日志发现gc过于频繁,很多gc都是几十秒甚至几分钟,监控情况请查看附件!
 
请问M大大,会有哪些原因会造成这种情况呢?
 
2.jpg 1.jpg
已邀请:

code4j - coder github: https://github.com/rpgmakervx

赞同来自: lz8086

提供一个线索,这两天我也遇到了节点gc问题,并最终解决了,我说下我的观点。
 
观察到您设置的threadpool.search.size 有100,也就是说业务高峰期,线程池中可能会滞留100个search线程,如果你的查询都是大查询,而线程并不释放(这个是fixed线程池决定的),就可能导致内存占用很大,特别是协调节点因为要汇总所有分片的结果,压力会更大。
 
 
建议把这个值放小点,最大不要超过核数1.5倍
 
 

novia - 1&0

赞同来自:

看你这数据量,不应该总是gc啊,查询业务每次是操作一个index还是多个?是不是aggs的业务非常多,而且非常频繁

yang009ww

赞同来自:

es挂掉的时候日志都是gc,而且gc时间都是几十秒,gc时间过长应该是主要原因,现在就是不知道是什么原因造成的!查询业务有单index,也有多index(通过别名),但是没超过3个,单index数据量在2000w内,有一些业务是聚合,跨2个index, 数据量1500w左右,没多少并发量,前端有通过nginx做缓存

novia - 1&0

赞同来自:

以前我们也遇到过这种情况,不过版本为1.7.3,当初的设计没有routing,没有doc_value

升级成2.1.1后,我们增加了路由,合理的设置了doc_value(所有需要aggs的全部设置),现在是一个片1500万,20G左右数据,一次最多访问4个片。就没有在出现频繁GC的情况,你可以参考下

yang009ww

赞同来自:

感谢您的建议,我们下个阶段准备针对索引进行全面优化,您的这些建议非常有价值,谢谢!
现在我们的单index最大不超过30G,分片5-8个!请问你们当初出现GC是通过一些什么样的手段来定位到具体的问题的呢?

medcl - 今晚打老虎。

赞同来自:

和你的查询有很大关系,如果有可能,升级新版本,内存使用有很大改善。

yang009ww

赞同来自:

M大,再请教一个问题,请查看图片附件。

1.jpg

 
这是一组es集群,3个节点配置一样,都是数据节点,也可以被选为主节点。但是发现节点1的搜索请求一直在堆积,而节点2和节点3的搜索请求并不多,这样导致节点1的请求队列超过设置的2000容量,则后续请求都被拒绝了。
为什么会出现这种情况?节点间不是会负载均衡吗?我该怎么处理这个问题呢?

Jokers - hi

赞同来自:

你这里用的什么监控???
 
我有ES 集群也是频繁出现GC,一共有14个数据节点。每个节点都会频繁的出现GC,一分钟大概出现4次。

Jokers - hi

赞同来自:

@code4j  那我的集群 threadpool.search.size  默认是1.5倍,他还是一直在频繁的 gc 。还有其他的思路吗?

要回复问题请先登录注册