05.global_index_setting_index相关全局设置

文章目录

1. 简介
2. Circuit breaker:
- 1. parent-level breaker设置
- - 1. indices.breaker.total.use_real_memory
  - 2. indices.breaker.total.limit
- 2. field-data 断路器
- 3. request 断路器
- 4. in-flight-request 断路器
- 5. 累积的已处理request断路器
- 6. script 编译断路器
3. Fielddata cache:
4. Node query cache:
5. Indexing buffer:
6. Shard request cache:
7. Recovery:
8. Search Settings:

1. 简介

这一篇了解的是index的全局设置，就是对所有的index都同时生效，且不能对某些index进行单独设置的setting

Circuit breaker: 内存断路器，防止过量的内存使用导致内存溢出
Fielddata cache: 对存于内存中的fielddata cache 的限制
Node query cache: 设置query results缓存使用的内存限制
Indexing buffer: 控制分配给index写入过程使用的buffer的size
Shard request cache: shard-level的request的cache使用限制
Recovery: 在shard recovery的过程中可以使用的资源
Search Settings: 全局的search相关的设置

2. Circuit breaker:

内存断路器，防止过量的内存使用导致内存溢出
Elasticsearch有多种breaker来防止内存溢出，每个breaker可以设置一个内存限制。同时，还有一个parent-level的breaker来设置所有的breaker可以使用的memory的总和

1. parent-level breaker设置

1. indices.breaker.total.use_real_memory

静态的设置，决定是否进行parent-level的memory使用统计，默认为true。如果为false那么久不会进行child breaker的内存使用统计了

2. indices.breaker.total.limit

parent-level breaker的使用限制。
这个的默认值会随着indices.breaker.total.use_real_memory的不同而不同。

indices.breaker.total.use_real_memory为true的话，这个值为JVM heap的95%
indices.breaker.total.use_real_memory为false的话，这个值为JVM heap的70%

2. field-data 断路器

这个断路器控制了es加载一个field的data使用的jvm内存限制，默认是jvm heap的40%。
可以通过下面的配置调整

indices.breaker.fielddata.limit: 使用的jvm内存限制，默认为40%
indices.breaker.fielddata.overhead: 如何估算多个fielddata的对内存的使用总和，是多个data field data的估算的和乘以一个系数，这个系数默认为1.03

3. request 断路器

这个breaker可以防止单个request的data导致了内存溢出。

indices.breaker.request.limit: 默认为60%，就是jvm heap的60%
Limit for request breaker, defaults to 60% of JVM heap
indices.breaker.request.overhead: 所有请求的使用的heap总量系数（会被用来乘以单个request的设置来得到总量值）,默认为1

4. in-flight-request 断路器

请求中的熔断器，允许Elasticsearch限制在transport或HTTP级别上的所有当前活动的传入请求的内存使用超过节点上的一定量的内存。内存使用是基于请求本身的内容长度。

network.breaker.inflight_requests.limit: (inflight_requests)请求中熔断器，默认为100％的JVM堆。这意味着受限于parent-level断路器配置的限制。
network.breaker.inflight_requests.overhead: 所有(inflight_requests)请求中估算的常数乘以确定最终估计。默认为1

5. 累积的已处理request断路器

这个breaker限制了那些已经处理完的请求仍然可以占用的内存，这一般都是值lucene segment占用的内存。

indices.breaker.accounting.limit: 默认为100％的JVM堆。这意味着受限于parent-level断路器配置的限制。
indices.breaker.accounting.overhead: 所有已处理的request使用的heap总量系数,默认为1

6. script 编译断路器

这个不是对内存限制，主要是限制一定时间执行的inline script 编译的数量

script.max_compilations_rate: 默认是75/5m, meaning 75 every 5 minutes

3. Fielddata cache:

fielddata cache 主要是在使用某个filed进行sort或者agg聚合操作的时候使用，会加载所有的field values到内存当中来是通过doc来获取这些field更加快速。这个需要大量的内存。而且只会针对使用text类型进行sort或者agg操作的时候会使用。

indices.fielddata.cache.size: 可以使用的内存限制，默认没有限制，可以限制为一个具体的数值12GB或者heap的百分比，比如30%,这个设置必须在每个data node上面设置。
可以使用Nodes Stats API 监控field-data使用的内存量。

4. Node query cache:

设置query results缓存使用的内存限制
每个node有一个所有shard共享的query cache,使用LRU的淘汰策略，进行cache的淘汰。并且只cache那些使用filter进行查询的query

下面的设置必须在每一个data-node上设置

indices.queries.cache.size: 默认为jvm-heap的10%，也可以设置为一个具体的大小，比如512mb
index.queries.cache.enabled: 是否对某个索引进行cache,可以针对具体的索引设置，默认为true

5. Indexing buffer:

控制分配给index写入过程使用的buffer的size ,这buffer用来存储新进来的doc,当buffer满了之后，这些doc 会被写入到磁盘中形成一个segment.这个buffer会被node上的所有shard瓜分。

cluster中的所有data-node都要有这些设置

indices.memory.index_buffer_size: 默认为jvm heap的10%
indices.memory.min_index_buffer_size: 在index_buffer_size使用百分比的方式设置的时候这个设置有效，默认为48mb
indices.memory.max_index_buffer_size: 在index_buffer_size使用百分比的方式设置的时候这个设置有效，默认为没有限制

6. Shard request cache:

shard-level的request的cache使用限制
shard request cache可以让热点请求瞬间返回，默认情况下只会cache size=0的查询，只会对hits.total, aggregations,suggestions进行缓存。

缓存会在shard进行refresh之后失效，也就是说缓存搜索出来的结果会保证和不适用缓存的效果一致。

这种对于日志型的查询很有用，比较老的index已经稳定了没有更新了，没有refresh，所以缓存不会失效，对于同样的查询，效果很好。

开启或者关闭caching

PUT /my_index
{"settings": {"index.requests.cache.enable": false}
}

cache使用的内存大小,默认为jvm heap的1%


indices.requests.cache.size: 2%

7. Recovery:

在shard recovery的过程中可以使用的资源
点对点的shard恢复是指从primary shard 往一个新的或者是已经存在的shard copy数据，发生的场景有：

在node failure 之后重新创建一个replica
relocate shard 操作

相关的设置有
1.indices.recovery.max_bytes_per_sec

动态设置，对每个node在recovery过程中使用的网络带宽进行限制，默认是40mb,这个限制只是针对单个node进行限制，如果设置的太大会占用较高的带宽，有可能影响其他操作,进而导致影响cluster的稳定性。

2.indices.recovery.max_concurrent_file_chunks
动态设置，而且是专家级的设置，在recovery的过程中chunk的并行度，在没有达到max_bytes_per_sec限制的情况下可以增大这个值来提升并行度。

8. Search Settings:

全局的search相关的设置
indices.query.bool.max_clause_count
默认这个值为1024
这个值会影响in查询的id数量，和boolean查询的条件数，其实这两个最后都重写成了lucene的booleanQuery

这种看样子只能通过重启es，修改配置才行。