關於elasticsearch使用G1垃圾回收替換CMS

最近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了，但是數據插入速度變慢了。