国际惯例先上图：
以上是目前我们部署的ES集群情况，最近其他业务团队有分析历史数据的诉求故此将历史的几个月之前的索引全部打开了，通过这几天的观察发现平均每天都会出现一次任意节点Full GC情况，现在怀疑到底是因为索引多、分片多就会导致节点GC？可能有的人会说将ES的垃圾回收策略改成G1，我也曾经试图尝试过最明显的即是Full GC频率降低了很多，但是毕竟官方不推荐使用。
用_cat/nodes这样的API也去看过目前各节点segment占用的内存只有10G+，剩余的20G内存到底去那儿了？？？很疑惑。
以上是目前我们部署的ES集群情况，最近其他业务团队有分析历史数据的诉求故此将历史的几个月之前的索引全部打开了，通过这几天的观察发现平均每天都会出现一次任意节点Full GC情况，现在怀疑到底是因为索引多、分片多就会导致节点GC？可能有的人会说将ES的垃圾回收策略改成G1，我也曾经试图尝试过最明显的即是Full GC频率降低了很多，但是毕竟官方不推荐使用。
用_cat/nodes这样的API也去看过目前各节点segment占用的内存只有10G+，剩余的20G内存到底去那儿了？？？很疑惑。
2 个回复
OnePunchMan - 人间有味是清欢。
赞同来自:
HelloClyde
赞同来自:
你是日志场景吗？试试冷热节点分离，然后加节点试下，看看业务方的一些query，如果游标查的多也会占用大量内存，fielddata也会占大量内存