es 由于gc 引起的节点脱落

作者: klause   发布时间:2017-09-01
最近发现es节点在gc时,引起节点脱落,将配置改成如下后,过了一阵又发生节点脱落的情况。discovery.zen.fd.ping_timeout: 60s
discovery.zen.fd.ping_interval: 10s
discovery.zen.fd.ping_retries: 10
 
这个配置值如何设置?另是否还有其他的解决方案
 
QQ图片20170901094128.png

9 个评论

我之前有遇到过es频繁gc,引起超时,我当时做了两个工作
1:增大了es的内存,esgc次数就明显下降了
2:设置indices.fielddata.cache.size: 20% 默认是无上限,并且常驻堆内存
我现在es的内存是32G的 逻辑上最大了 我现在加大超时时间 重试间隔 重试次数 还是会引起节点脱落 我现在加上indices.fielddata.cache.size 试一下
恩恩, 那内存已经不小了,你安装个监控软件bigdest看一下具体的集群运行情况,根据你自己的实际情况去调参数,效果应该会比较好,安装脚本如下
# git clone https://github.com/hlstudio/bigdesk
# cd bigdesk/_site
# python -mSimpleHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...
好的 谢谢指点
haha 不客气,我也是一步一步在群里大神的指引下走过来的
如果确认脱落是因为结点长时间GC造成的,很大可能是存在一些高消耗的查询或者聚合。 最好是对集群的查询都有log,根据GC发生时间,分析可能造成问题的查询。
感谢您的建议! 如果再发生这种情况 加上log排查一下
大神,目前有个ES集群一直在导数据,一小时大概一百万数据,发现有个节点的日志里在频繁young gc,有个别old gc时间超过2分钟,导致节点下线。内存分配了32G。没有feilddata缓存,这种情况应该怎么调啊,除了修改ping_timeout时间。
[2017-12-19 19:28:10,223][WARN ][monitor.jvm ] [hdh5] [gc][old][409891][46] duration [2.2m], collections [1]/[2.6m], total [2.2m]/[20.3m], memory [12.4gb]->[10.5gb]/[31.8gb], all_pools {[young] [1gb]->[28.7mb]/[1.1gb]}{[survivor] [147.9mb]->[0b]/[149.7mb]}{[old] [11.3gb]->[10.5gb]/[30.5gb]}
是不是所有的请求都是连接的这个节点?另外默认的cms 不太适合大场景 推荐g1 另外需要合理的角色分配

要回复文章请先登录注册