十、JVM调优实战——ES集群服务不稳定

1、问题背景

线上环境有3台8G内存的服务器搭建的ES集群系统。ES采用CMS垃圾回收器。

2、问题现象

（1）ES查询服务偶尔会出现超时现象，日志中有“node of configured nodes were available”；
（2）一段时间后，ES部分节点会挂掉，整个ES集群的状态由绿色变成黄色；
（3）重启后，ES恢复正常，运行一段时间后会出现（2）的现象。

3、问题分析

（1）ES集群提供的查询服务，非常消耗内存，所以首先想到的就是8G内存无法支撑我们系统千万级别的数据查询。
（2）登陆系统查看报错，有关于垃圾回收的日志如下。

[2021-08-02 10:18:14,037][INFO ][monitor.jvm              ] [IPADDRS-9300] [gc][young][216907][612] duration [765ms], collections [1]/[1.7s], total [765ms]/[57.6s], memory [4.9gb]->[4.9gb]/[7.9gb], all_pools {[young] [190.8mb]->[5mb]/[266.2mb]}{[survivor] [33.2mb]->[33.2mb]/[33.2mb]}{[old] [4.6gb]->[4.9gb]/[7.6gb]}
[2021-08-02 10:19:05,077][INFO ][monitor.jvm              ] [IPADDRS-9300] [gc][young][216958][616] duration [718ms], collections [1]/[1s], total [718ms]/[59.8s], memory [5.8gb]->[5.8gb]/[7.9gb], all_pools {[young] [263.5mb]->[4.7mb]/[266.2mb]}{[survivor] [33.2mb]->[33.2mb]/[33.2mb]}{[old] [5.6gb]->[5.8gb]/[7.6gb]}
[2021-08-02 10:20:36,308][WARN ][monitor.jvm              ] [IPADDRS-9300] [gc][old][217020][21] duration [28.6s], collections [1]/[29.4s], total [28.6s]/[47.2s], memory [6.5gb]->[6.5gb]/[7.9gb], all_pools {[young] [178.9mb]->[50.4kb]/[266.2mb]}{[survivor] [33.2mb]->[0b]/[33.2mb]}{[old] [6.3gb]->[6.5gb]/[7.6gb]}
[2021-08-02 10:21:08,913][WARN ][monitor.jvm              ] [IPADDRS-9300] [gc][old][217035][22] duration [17.8s], collections [1]/[18s], total [17.8s]/[1m], memory [7.1gb]->[7.2gb]/[7.9gb], all_pools {[young] [14.6mb]->[12.4kb]/[266.2mb]}{[survivor] [33.2mb]->[0b]/[33.2mb]}{[old] [7.1gb]->[7.2gb]/[7.6gb]}
[2021-08-02 10:22:18,270][WARN ][monitor.jvm              ] [IPADDRS-9300] [gc][old][217078][25] duration [27.1s], collections [1]/[27.1s], total [27.1s]/[1.5m], memory [7.8gb]->[6.5gb]/[7.9gb], all_pools {[young] [252.3mb]->[4.1mb]/[266.2mb]}{[survivor] [3.6mb]->[0b]/[33.2mb]}{[old] [7.6gb]->[6.5gb]/[7.6gb]}
[2021-08-02 10:22:54,407][WARN ][monitor.jvm              ] [IPADDRS-9300] [gc][old][217083][26] duration [29.9s], collections [1]/[30.7s], total [29.9s]/[2m], memory [7.6gb]->[7.8gb]/[7.9gb], all_pools {[young] [2.2mb]->[228.2mb]/[266.2mb]}{[survivor] [33.2mb]->[0b]/[33.2mb]}{[old] [7.6gb]->[7.6gb]/[7.6gb]}
[2021-08-02 10:22:54,409][DEBUG][action.admin.cluster.node.stats] [IPADDRS-9300] failed to execute on node [tYMvYmijTgOe5maeJ145zg]

观察日志发现：
（1）年轻代内存过小，只有225MB；
（2）年轻代内存过小导致频繁发生young gc；
（3）每次young gc，大概就会有200-300MB的数据进入老年代，说明这是一次无效的young gc；并没有释放内存，只是把数据从年轻代转移到了老年代。
（4）老年代内存设置为7.6G，但是内存增长速率非常快，和（3）有很大关系看；
（5）由于老年代内存增长很快，CMS如下的设置。当内存使用率接近70%，也就是5.7G时，会出发old GC；CMS在再次标记阶段会stop the world，导致服务不可用；
（6）由于old gc频繁，导致回收时，大部分对象还没有失效，回收效率低。

-XX:CMSInitiatingOccupancyFraction=75 //老年代内存使用率超过75%触发垃圾回收

总结：年轻代设置过小，导致频繁无效的young gc，很快把对象都放入了老年代中，一段时间后就会把老年代占满；导致频繁old gc。cms会stop the world，导致服务不可以用，甚至出现OOM。

4、解决方法

8G内存，按照1:2设置年轻代和老年代的内存大小；