Circuit breaker
断路器对内存的使用设定了限制,以避免出现内存不足的异常。
Fielddata cache
对内存中Fielddata缓存所使用的堆的数量设置限制。
Node query cache
配置用于缓存查询结果的堆积量。
Indexing buffer
控制分配给索引写入过程的缓冲区的大小。
Shard request cache
控制分片级请求缓存的行为。
Recovery
控制分片恢复过程中的资源限制。
Search Settings
控制全局搜索设置。
Elasticsearch包含多个断路器,用于防止操作导致OutOfMemoryError。每个断路器都规定了它可以使用的内存数量的限制。此外,还有一个父级断路器,规定了所有断路器可使用的内存总量。以下为动态配置。
父级断路器indices.breaker.total.limit
,父级断路器的起始限制,默认为JVM堆的70%。
字段数据断路器允许Elasticsearch估计一个字段加载到内存中所需要的内存量。然后,它可以通过引发一个异常来阻止字段数据的加载。默认情况下,该限制被配置为大JVM堆的60%。它可以通过以下参数进行配置。
indices.breaker.fielddata.limit
:对Fieldddata断路器的限制,默认为JVM堆的60%。
indices.breaker.fielddata.overhead
:感觉是因素值,指一个常数,所有的字段数据估计都与之相乘,以确定最终的估计值。默认为1.03。
请求断路器允许Elasticsearch防止每个请求的数据结构(例如,在请求期间用于计算聚合的内存)超过一定的内存量。
indices.breaker.request.limit
:对请求断路器的限制,默认为JVM堆的60%。
indices.breaker.request.overhead
:感觉是因素值,指一个常数,所有的请求估计都与之相乘,以确定最终的估计值。默认为1。
正在传输的请求断路器允许Elasticsearch限制传输或HTTP级别上所有当前活动的传入请求的内存使用,避免超过一个节点上的特定内存量。内存使用情况取决于请求本身的内容长度。
network.breaker.inflight_requests.limit
:正在传输的请求断路器的限制, 默认为JVM堆的100%. 这意味着它受到为上级断路器配置的限制的约束。
network.breaker.inflight_requests.overhead
:感觉是因素值,指一个常数,所有的正在传输的请求估计都与之相乘,以确定最终的估计值。默认为1。
会计断路器允许Elasticsearch限制内存中的东西的使用,这些东西在请求完成后不会被释放。这包括像Lucene段内存这样的东西。
indices.breaker.accounting.limit
:会计断路器的限制, 默认为JVM堆的100%. 这意味着它受到为上级断路器配置的限制的约束。
indices.breaker.accounting.overhead
:感觉是因素值,指一个常数,所有的会计断路器估计都与之相乘,以确定最终的估计值。默认为1。
与之前基于内存的断路器略有不同,脚本编译断路器限制了一段时间内内联脚本编译的数量。
script.max_compilations_rate
:在一定的时间间隔内,允许编译的独特动态脚本的数量限制。默认为75/5m,即每5分钟75个。
字段数据缓存主要在对字段进行排序或计算聚合时使用。它将所有字段的值加载到内存中,以便提供基于文档的对这些值的快速访问。为一个字段建立字段数据缓存可能很昂贵,所以建议有足够的内存来分配它,并保持它的加载。
用于字段数据缓存的内存量可以用indices.fielddata.cache.size
来控制。注意:重新加载不适合你的缓存的字段数据将是昂贵的,而且性能很差。
indices.fielddata.cache.size
静态配置
字段数据缓存的大值,例如节点堆空间的30%
,或者一个绝对值,例如12GB
。默认为unbounded,不限制。
query cache负责对查询结果进行缓存。每个节点有一个查询缓存,由所有分片共享。缓存实现了LRU驱逐策略:当缓存变满时,最近使用最少的数据被驱逐,以便为新数据让路。被缓存的内容无法查看。
查询缓存只缓存在过滤器上下文中使用的查询。
必须在集群中的每个数据节点上进行配置。
indices.queries.cache.size
静态配置
控制过滤器缓存的内存大小,默认为10%
。接受一个百分比值,如5%
,或一个精确的值,如512mb
。
索引级别的配置,可以在每个索引的基础上进行配置。
index.queries.cache.enabled
控制是否启用查询缓存。值为true
(默认)或false
。
索引缓冲区用于存储新索引的文件。当它填满时,缓冲区中的文件被写入磁盘上的一个段。它被分发到节点上的所有分片中。
下面的设置是静态的,必须在集群中的每个数据节点上进行配置。
indices.memory.index_buffer_size
值为一个百分比或一个字节大小的值。它默认为10%
,意味着分配给节点的总堆的10%
将被用作所有分片共享的索引缓冲区大小。
indices.memory.min_index_buffer_size
如果index_buffer_size
被指定为一个百分比,那么这个设置可以用来指定一个绝对最小值。默认为48mb
。
indices.memory.max_index_buffer_size
如果index_buffer_size
被指定为一个百分比,那么这个设置可以用来指定一个绝对的大值。默认值为unbounded。
当针对一个索引或许多索引运行搜索请求时,每个参与的分片在本地执行搜索,并将其本地结果返回给协调节点,后者将这些分片级的结果合并为一个 "全局"结果集。
分片级请求缓存模块将本地结果缓存在每个分区内。这使得经常使用的(和潜在的大量)搜索请求几乎可以立即返回结果。请求缓存非常适用于日志的使用情况,在这种情况下,只有最近的索引被主动更新–来自较早索引的结果将直接从缓存中提供。
Cache invalidation缓存很聪明–它保持了与未缓存搜索相同的近实时承诺。
每当分片区刷新时,缓存的结果就会自动失效,但只有当分片区的数据确实发生了变化。换句话说,你从缓存中得到的结果总是与未缓存的搜索请求相同。
刷新间隔时间越长,缓存条目保持有效的时间就越长。如果缓存已满,最近使用最少的缓存键将被驱逐。
缓存可以通过[clear-cache
API]手动过期。
curl -X POST "localhost:9200/kimchy,elasticsearch/_cache/clear?request=true&pretty"
Enabling and disabling caching缓存在默认情况下是启用的,但在创建新的索引时可以禁用,方法如下:
curl -X PUT "localhost:9200/my_index?pretty" -H 'Content-Type: application/json' -d'
{
"settings": {
"index.requests.cache.enable": false
}
}
'
它也可以通过[update-settings
API]在一个现有的索引上动态地启用或禁用。
curl -X PUT "localhost:9200/my_index/_settings?pretty" -H 'Content-Type: application/json' -d'
{ "index.requests.cache.enable": true }
'
Enabling and disabling caching per requestTherequest_cache
query-string parameter can be used to enable or disable caching on a per-request basis. If set, it overrides the index-level setting:
request_cache
查询字符串参数可以用来启用或禁用per-request的缓存。如果设置,它将覆盖索引级的设置。
curl -X GET "localhost:9200/my_index/_search?request_cache=true&pretty" -H 'Content-Type: application/json' -d'
{
"size": 0,
"aggs": {
"popular_colors": {
"terms": {
"field": "colors"
}
}
}
}
'
如果你的查询使用了一个结果不确定的脚本(例如,它使用了一个随机函数或引用了当前时间),你应该把
request_cache
标志设置为false
,以禁止对该请求进行缓存。
即使在索引设置中启用了请求缓存,size
大于0的请求也不会被缓存。为了缓存这些请求,你需要使用这里详述的query-string参数。
整个JSON主体被用作缓存密钥。这意味着,如果JSON发生变化–例如,如果键以不同的顺序输出–那么缓存键将无法被识别。
大多数JSON库支持规范模式,确保JSON键总是以相同的顺序排放。这种规范模式可以在应用程序中使用,以确保请求总是以相同的方式被序列化。
Cache settings缓存是在节点级别管理的,默认的大大小为堆的1%
。这可以在config/elasticsearch.yml
文件中修改。
indices.requests.cache.size: 2%
另外,你可以使用indices.requests.cache.expire
设置来指定缓存结果的TTL,但应该没有理由这样做。记住,当索引被刷新时,过期的结果会自动失效。这个设置仅仅是为了完整起见而提供的。
缓存的大小(以字节为单位)和驱逐的数量可以通过索引查看,使用[indices-stats
]API。
curl -X GET "localhost:9200/_stats/request_cache?human&pretty"
或用[nodes-stats
]API按节点进行统计。。
curl -X GET "localhost:9200/_nodes/stats/indices/request_cache?human&pretty"
Indices Recovery对等恢复(Peer recovery)将数据从一个主分片同步到一个新的或现有的分片副本。
在Elasticsearch中,对等恢复会自动发生。
你可以使用cat recovery API查看正在进行和已经完成的恢复的列表。
Peer recovery settingsindices.recovery.max_bytes_per_sec
([动态])
限制每个节点的入站和出站恢复总流量。默认为40mb
。此限制只适用于节点。如果集群中的多个节点同时执行恢复,集群的总恢复流量可能会超过这个限制。如果这个限制太高,正在进行的恢复可能会消耗过多的带宽和其他资源,这可能会破坏集群的稳定。
你可以使用以下专家设置来管理对等恢复的资源。
indices.recovery.max_concurrent_file_chunks
([动态], Expert)
每次恢复时并行发送的文件块请求的数量。默认为2
。当单个分片的恢复没有达到indices.recovery.max_bytes_per_sec
设置的流量限制时,你可以增加这个设置值。
可以设置以下专家*设置来管理全局搜索限制。
indices.query.bool.max_clause_count
Defaults to1024
.
这个设置限制了Lucene BooleanQuery的子句数量。默认的1024是相当高的,通常应该是足够的。这个限制不仅影响Elasticsearch的bool
查询,而且许多其他查询在内部被改写为Lucene的BooleanQuery。这个限制的存在是为了防止搜索变得过大,占用过多的CPU和内存。如果你考虑增加这个设置,请确保你用尽了所有其他的选项,以避免不得不这样做。更高的值可能导致性能下降和内存问题,特别是在高负载或资源少的集群中。
你是否还在寻找稳定的海外服务器提供商?创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源,准确流量调度确保服务器高可用性,企业级服务器适合批量采购,新人活动首月15元起,快前往官网查看详情吧
售后响应及时
7×24小时客服热线数据备份
更安全、更高效、更稳定价格公道精准
项目经理精准报价不弄虚作假合作无风险
重合同讲信誉,无效全额退款