阅读本文前,请先阅读ES内存分析。 ES默认配置下,heap是存在超卖情况的。
类目 | 默认占比 | 是否常驻 | 淘汰策略(在控制大小情况下) | 控制参数 |
---|---|---|---|---|
query cache | 10% | 是 | LRU | indices.queries.cache.size |
request cache | 1% | 是 | LRU | indices.requests.cache.size |
fielddata cache | 无限制 | 是 | LRU | indices.fielddata.cache.size |
segment memory | 无限制 | 是 | 无 | 不能通过参数控制 |
common space | 70% | 否 | GC | 通过熔断器 indices.breaker.total.limit 限制 |
common space(可GC)
子类目 | 默认占比 | 控制参数 |
---|---|---|
indexing buffer | 10% | indices.memory.index_buffer_size |
request agg data | 60% | indices.breaker.request.limit |
in-flight data | 100% | network.breaker.inflight_requests.limit |
通过上表可知,segment memory是非常重要,而且是不可通过参数干预的内存空间,而cache部分则可以提升性能,可以被清除。common space 是运行时的动态空间,可以被GC。
综上所述,需要保证segment memory+cache+common space不超过100%。由于熔断器是按整个heap大小来计算的,所以如果segment memory 过大,仍然可能会导致OOM。为了减少这种情况的发生,需要预留足够空间给segment。 优化
- 限制fielddata大小,fielddata是针对text类型进行排序、聚合才用到。正常应该避免这种情况发生。
- 限制request agg data大小,这个参数会影响聚合使用的内存,如果触发熔断,业务需要进行优化。
内存分配
segment memory
|
预留10%
|
|
fielddata cache
|
限制在20%
|
|
query cache
|
限制10%
|
|
request cache
|
限制1%
|
|
indexing buffer
|
限制10%
|
|
request agg data
|
限制1%
|
父熔断器配置30%,扣除fielddata,agg剩余的就是in-flight
|
in-flight data
|
限制9%
|
参数设置
indices.fielddata.cache.size:1%--需要重启节点
PUT _cluster/settings
{
"persistent": {
"indices.breaker.fielddata.limit":"20%",
"indices.breaker.request.limit":"1%",
"indices.breaker.total.limit":"70%"
}
}
[尊重社区原创,转载请保留或注明出处]
本文地址:http://searchkit.cn/article/699
本文地址:http://searchkit.cn/article/699
2 个评论
请问request agg data 和in-flight data 分别是什么数据
request agg data 存储的是计算agg需要的数据,通过熔断器控制单个query占用的空间大小,in-flight data 是当前请求的请求体大小,通过熔断器来限制并发请求流量。官网:https://www.elastic.co/guide/en/elasticsearch/reference/current/circuit-breaker.html