Elasticsearch - index.fielddata.cache.size 和 indices.fieldda



Elasticsearch 不稳定的最大原因之一是字段数据:字段值必须加载到内存中才能使聚合、排序和脚本执行得尽可能快。

正如上面在 Elasticsearch 页面上的描述,大型字段数据总是会导致 Elasticsearch 内存不足 (OOM)。因此,我们可以设置 index.fielddata.cache.size 和 indices.fielddata.breaker.limit 来防止 OOM。这两种设置之间有什么区别?他们有什么关系吗?

例如,My Elasticsearch JVM 的总内存为 2g。如果我将 index.fielddata.cache.size 设置为 1g,但 index.fielddata.breaker.limit 设置为 60%(这意味着 1.2g)。允许加载到内存的字段数据超过字段数据缓存大小。它会导致任何错误吗?(参考字段数据)

谢谢。

经过长时间的研究,我找到了一些答案。

当您将 index.fielddata.cache.size 设置为 1g 时。这意味着 elasticsearch 可以使用多少字段缓存大小来处理查询请求。但是当你将 index.fielddata.breaker.limit 设置为 60%(表示 1.2g)时,如果查询数据大于此大小,elasticsearch 将拒绝此查询请求并导致异常。

因此,如果查询数据小于 1.2g 但大于 1g,则 elassticsearch 将接受此查询请求。到达 index.fielddata.cache.size 后,旧数据将被刷新并为新数据释放内存。

他们的区别是,我引用

加载数据后检查字段数据大小。如果到达的查询试图加载到字段数据中超过可用内存的内容,会发生什么情况?答案是丑陋的:你会得到一个 OutOfMemoryException。

Elasticsearch包含一个现场数据断路器,旨在处理这种情况。断路器通过自检所涉及的字段(其类型、基数、大小等)来估计查询的内存要求。然后,它会检查加载所需的字段数据是否会将总字段数据大小推到配置的堆百分比以上。

如果估计的查询大小大于限制,则断路器将跳闸,查询将中止并返回异常。这发生在加载数据之前,这意味着您不会遇到 OutOfMemoryException。

来自限制内存使用。

相关内容

最新更新