绊脚石乃是进身之阶。

Es Filelddata 占用6G的jvm堆内存 ,_cache/clear清理后,马上又占用了6G,频繁full gc

Elasticsearch | 作者 artisan | 发布于2021年07月14日 | 阅读数:745

服务器信息: Redhat Oracle , 20Core  96G 内存,非SSDES版本号 :6.4.1
 
业务背景: 
1)   ES运行2个月+, 目前存量数据 1千万+ .  ES 堆内存 16G  .  indices.fielddata.cache.size 设置的为 40% 
2)   索引为父子文档  
3)   一直有业务不间断的向ES写入数据, 有个业务逻辑会根据fileCode去检索是否存在父文档中
 
 
想请教下,这个Fielddata 中的 my_join_file#my_parent 和 fileCode, 再清理了缓存后(_cache/clear) ,很快就被占满了,是因为 业务中需要查询数据,然后ES又重新加载了一遍么? 
 
请教问题二:  目前full gc 频率很高 ,如何规避这种情况? 
 
请教问题三:  第二个图为 当前机器的内存使用情况, cache已经使用了70G+ , 实际索引磁盘大小 40G不到,这部分cache 都被什么占据了? 
 
 
 
 
QQ图片20210714161245.png Snipaste_2021-07-14_16-14-09.png
已邀请:

Ombres

赞同来自: artisan

1. 感觉是字段没有启用doc_values,或者是已启用doc_values,但是这俩字段的值基本上都是非重复数据
2. jvm的堆内存占用过多导致full gc,解决第一个问题应该就会好转
3. lucene通过mmap使用堆外内存,将部分文件映射到内存中,表现为占用cache,如果操作系统有需要,会随时清除部分cache

tongchuan1992 - 学无止境、学以致用

赞同来自: artisan

1.清理之后应该还是有查询请求去查数据了吧,导致数据进行了缓存。
2.你的内存这么多,建议把java堆内存设置成32g,看起来1一千万数据量也不多,感觉用不到这么多内存,可能你的字段非常多,然后查询的时候获取的数据量也很多,就会频繁导致full gc。
3.cache是被Lucene占用了,他使用的堆外内存,有多少用多少。用的越多,数据查询越快。

zqc0512 - andy zhou

赞同来自: artisan

索引为父子文档  想办法调整下这个。嵌套,数组 对查询性能影响大,你这点数据量 ES JVM建议搞到32G 应该没撒问题的。

要回复问题请先登录注册