使用背景

用于年底需要出一些统计的数据需求，原始数据存储与MySQL中，在短时间内做聚合统计查询上，MySQL显然支撑不起来，统计速度太慢，容易飙高CPU内存资源，所以引入ES做聚合统计查询。本次使用的是elasticsearch7.4.0版本的。

异常描述

在数据写入的时候，通过kibana的堆栈检测查看JVM堆一直持续走高，然后就开始报Data too large.....

注意事项

因为环境不同，配置不同，异常不同，所以本文的解决方法只提供参考，请自行判断修改的可行性后再行修改。

解决过程

参考百度，如下修改。

1、修改ES的JVM内存值，修改了ES安装目录中的config文件夹下的jvm.options文件。

-Xms1g

-Xmx1g

根据官方建议，为避免在运行过程中再进行内存分配，这两个值应当设置成一样的，设置值建议为物理内存的一半且不超过32g。

2、修改缓冲区大小

通过kibana的开发工具进行修改。

 PUT /_cluster/settings
 {
     "persistent": {
     	"indices.breaker.fielddata.limit": "60%"
     }
 }

 PUT /_cluster/settings
 {
     "persistent": {
     	"indices.breaker.request.limit": "40%"
     }
 }

 PUT /_cluster/settings
 {
     "persistent": {
     	"indices.breaker.total.limit": "70%"
     }
 }

3、修改JVM的GC配置，及时释放内存，避免内存溢出，减少OOM异常的发生概率。

-XX:CMSInitiatingOccupancyFraction=75 这个值默认75，值老年代使用到75就回收，但是建议该值设置小于“indices.breaker.total.limit”值（70%）。可以设置成65或者60。

-XX:MaxTenuringThreshold设置成10，这个值默认15，意思是Survivor区对象经历过10次新生代GC后就进入老年代。