首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >ES集群V7.3.1频繁发生断路异常?

ES集群V7.3.1频繁发生断路异常?
EN

Stack Overflow用户
提问于 2021-02-12 16:48:29
回答 2查看 176关注 0票数 2

我们使用的是ES v7.3.1,在过去的几天里,我们的ES集群中的分片因为电路中断异常而被取消分配,我不能理解导致这个异常的确切原因,任何帮助都会非常有帮助。

这是我使用get _cluster/allocation/explain命令获得的详细信息

代码语言:javascript
复制
"unassigned_info" : {
    "reason" : "ALLOCATION_FAILED",
    "at" : "2021-02-12T08:05:40.154Z",
    "failed_allocation_attempts" : 1,
    "details" : "failed shard on node [WbHklo7iSf6jGj90cP9Y-A]: failed to perform indices:data/write/bulk[s] on replica [segment_index_573179789d2572f27bc73e6b][6], node[WbHklo7iSf6jGj90cP9Y-A], [R], s[STARTED], a[id=SNoWjhhYRXClfVqa6lsDAQ], failure RemoteTransportException[[ip-1-0-104-220][1.0.104.220:9300][indices:data/write/bulk[s][r]]]; nested: CircuitBreakingException[[parent] Data too large, data for [<transport_request>] would be [14311120802/13.3gb], which is larger than the limit of [14247644364/13.2gb], real usage: [14311004440/13.3gb], new bytes reserved: [116362/113.6kb], usages [request=0/0b, fielddata=808714408/771.2mb, in_flight_requests=15836072/15.1mb, accounting=683535018/651.8mb]]; ",
    "last_allocation_status" : "no_attempt"
  }
EN

回答 2

Stack Overflow用户

发布于 2021-02-12 16:55:45

您的分片分配解释API提供了解决该问题所需的所有详细信息

  1. indices:data/write/bulk正在导致发生问题的电路breaker.
  2. WbHklo7iSf6jGj90cP9Y-A节点。segment_index_573179789d2572f27bc73e6b
  3. below是正在发送的实际限制和数据,它发生在副本碎片上。
  4. 正在导致数据断路器。

您的节点上正在发生Parent circuit breaker,如日志行中所述,我已经突出显示了,实际限制为13.2 GB,但在批量请求中,您将发送13.3 GB的数据。

CircuitBreakingException[parent数据太大,的数据将为14311120802/13.3 be,大于限制14247644364/13.2 be,实际使用量:14311004440/13.3 be,保留的新字节数: 116362/113.6kb

解决方案

您可以减小批量请求的大小,以避免这种断路器

票数 0
EN

Stack Overflow用户

发布于 2021-02-12 21:44:12

您能提供集群运行状况的结果吗?

代码语言:javascript
复制
curl -XGET  "http://localhost:9200/_cluster/health?pretty"

您能提供JVM压力度量的结果吗?

由于没有太多信息,下面我将解释在类似的电路中断情况下发生在我身上的情况,以及我在我的情况下所做的事情。

我确信块大小很小,几件事情(搜索+块+新分片的分配过程)的总和会导致RAM填满。

据我所知,“数据太大”指的是JVM堆。也许,您已经达到内存限制,从而触发了断路器。我敢想(很有可能是错的:/ )每个节点的ram与配置的断路器的百分比成正比。例如,如果您将断路器设置为80%,并且显示13.3 GB的错误,则每个节点肯定有16 GB的RAM (100%)。

如果你的断路器已经很高,那就不建议调高它。

有些情况下,创建新索引的逻辑/模式是不正确的,它们会无意中生成许多新索引(创建许多分片),而不是只创建一个索引。

也许您已经达到了极限,但您并不知道这一点,直到现在您创建了新的索引(因此创建了新的分片),问题才出现。

当您使用shard达到限制偏移时,您可以减少副本分片的数量,作为临时解决方法。才能完成大块的工作。

一个对我有效的选项是禁用不太重要的索引的临时碎片副本。

检查你的分片:curl -XGET "http://localhost:9200/_cat/shards"

代码语言:javascript
复制
curl -X "PUT"  "http://localhost:9200/mylessimportant_indices/_settings" \
-H "Content-type: application/json" \
-d $'{
"index" : {
"number_of_replicas":0
}
}' | jq
票数 0
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/66168742

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档