最近发现es节点在gc时，引起节点脱落，将配置改成如下后，过了一阵又发生节点脱落的情况。discovery.zen.fd.ping_timeout: 60s
discovery.zen.fd.ping_interval: 10s
discovery.zen.fd.ping_retries: 10
这个配置值如何设置？另是否还有其他的解决方案
discovery.zen.fd.ping_interval: 10s
discovery.zen.fd.ping_retries: 10
这个配置值如何设置？另是否还有其他的解决方案
[尊重社区原创，转载请保留或注明出处]
本文地址：http://elasticsearch.cn/article/252
本文地址：http://elasticsearch.cn/article/252
9 个评论
我之前有遇到过es频繁gc,引起超时，我当时做了两个工作
1：增大了es的内存，esgc次数就明显下降了
2：设置indices.fielddata.cache.size: 20% 默认是无上限，并且常驻堆内存
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 ...
# 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发生时间，分析可能造成问题的查询。
大神，目前有个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]}
[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]}
klause 回复 zhangg7723
是不是所有的请求都是连接的这个节点？另外默认的cms 不太适合大场景 推荐g1 另外需要合理的角色分配
