最近ES集群数据节点经常出现jvm占用过高，频繁GC导致ES集群卡死，很长时间才恢复。在网上看到用G1垃圾回收可以改善这一情况，但都是老版本的ES，我们现在使用的版本是5.5.2，所以想问问各位5.5.2版本的ES能不能改用G1垃圾回收，另外要怎么改为G1，因为以前的版本都是在elasticsearch.in.sh文件中改JAVA_OPTS的配置，但在5.5.2版本中已找不到这个配置，好像在jvm.options文件中，但是不知道具体怎么改。求救~~
###############
我们线上的集群从5.3.2 - 6.2.4都有用G1的，没有什么问题。 修改jvm.options文件，将下面几行:
-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly
更改为
-XX:+UseG1GC
-XX:MaxGCPauseMillis=50
即可。
其中 -XX:MaxGCPauseMillis是控制预期的最高GC时长，默认值为200ms，如果线上业务特性对于GC停顿非常敏感，可以适当设置低一些。但是 这个值如果设置过小，可能会带来比较高的cpu消耗。
G1对于集群正常运作的情况下减轻G1停顿对服务时延的影响还是很有效的，但是如果是你描述的GC导致集群卡死，那么很有可能换G1也无法根本上解决问题。 通常都是集群的数据模型或者Query需要优化。
再次请问一下，替换为G1的话，是不是某种意义上可以减少GC的次数呢？或者说替换G1的好处体现在哪儿，不是太理解。
G1的停顿时间可以预测，相比CMS更加容易控制GC停顿时间。 另外G1不会像CMS那样产生内存碎片，对于大堆回收垃圾的效率更高。 就我们线上的实际应用情况看，对ES使用G1以后，Young GC的频率和耗时都可以极大的降低，Old GC几乎不会出现。
还有一个问题想请问下您，我最近要添加两个节点，我想在新加的两个节点直接配置使用G1，以前的节点暂时不改继续使用CMS，这样可以嘛？
可以的
#########
我觉得改垃圾回收器也不能解决你GC耗时过久的问题。要从根本上先分析GC耗时高的原因，通常来说都是因为堆分配太多了，而内存又都是常驻的，所以GC一次需要遍历的内存区太多导致耗时很久。
之前我们有一个日志集群，32G的堆，由于索引太多了导致master节点的内存被占满了，每次GC耗时1分钟多。
而我们有一个服务，内存只有512M，每次GC耗时只有几十毫秒。
所以先分析集群为什么会吃这么大内存吧
##################
G1GC官方推荐的jdk版本是JDK11,9开始默认使用G1，之前默认CMS，而且jdk8我改成G1是不会发生GC了，但是数据插入速度变慢了。
