在顺利地工作了10个多月后,我在做简单的搜索查询时突然开始在生产中出现这个错误。
{
"error" : {
"root_cause" : [
{
"type" : "circuit_breaking_exception",
"reason" : "[parent] Data too large, data for [<http_request>] would be [745522124/710.9mb], which is larger than the limit of [745517875/710.9mb]",
"bytes_wanted" : 745522124,
"bytes_limit" : 745517875
}
],
"type" : "circuit_breaking_exception",
"reason" : "[parent] Data too large, data for [<http_request>] would be [745522124/710.9mb], which is larger than the limit of [745517875/710.9mb]",
"bytes_wanted" : 745522124,
"bytes_limit" : 745517875
},
"status" : 503
}
最初,我得到这个错误,而做简单的术语查询时,我得到这个circuit_breaking_exception错误,为了调试这个我尝试了_cat/health查询elasticsearch集群,但仍然,同样的错误,即使是最简单的查询localhost:9200也给出同样的错误不知道发生了什么集群突然.她是我的断路器状态:
"breakers" : {
"request" : {
"limit_size_in_bytes" : 639015321,
"limit_size" : "609.4mb",
"estimated_size_in_bytes" : 0,
"estimated_size" : "0b",
"overhead" : 1.0,
"tripped" : 0
},
"fielddata" : {
"limit_size_in_bytes" : 639015321,
"limit_size" : "609.4mb",
"estimated_size_in_bytes" : 406826332,
"estimated_size" : "387.9mb",
"overhead" : 1.03,
"tripped" : 0
},
"in_flight_requests" : {
"limit_size_in_bytes" : 1065025536,
"limit_size" : "1015.6mb",
"estimated_size_in_bytes" : 560,
"estimated_size" : "560b",
"overhead" : 1.0,
"tripped" : 0
},
"accounting" : {
"limit_size_in_bytes" : 1065025536,
"limit_size" : "1015.6mb",
"estimated_size_in_bytes" : 146387859,
"estimated_size" : "139.6mb",
"overhead" : 1.0,
"tripped" : 0
},
"parent" : {
"limit_size_in_bytes" : 745517875,
"limit_size" : "710.9mb",
"estimated_size_in_bytes" : 553214751,
"estimated_size" : "527.5mb",
"overhead" : 1.0,
"tripped" : 0
}
}
我在这里发现了一个类似的问题Github Issue,建议增加断路器内存或禁用相同的。但我不知道该选择什么。请帮助!
ElasticSearch版本6.3
3条答案
按热度按时间t3irkdon1#
经过进一步的研究,我终于找到了一个解决办法,即
1.我们不应该禁用断路器,因为它可能会导致OOM错误,并最终可能崩溃ElasticSearch。
1.动态地增加断路器存储器百分比是好的,但是它也是临时的解决方案,因为在解决方案之后,增加的百分比也可能填满。
1.最后,我们还有第三种选择,即增加总体JVM堆大小,默认情况下为1GB,但建议在生产环境中大约为30-32 GB,而且应该少于可用总内存的50%。
有关更多信息,请查看此文章,以了解生产环境中ElasticSearch的良好JVM内存配置,Heap: Sizing and Swapping
ckx4rj1h2#
在我的例子中,我有一个包含大型文档的索引,每个文档都有**~30 KB和超过130个字段**(嵌套对象、数组、日期和ID)。我使用以下DSL查询搜索所有字段:
因为全文搜索的成本很高。同时搜索多个字段的成本甚至更高。成本是在计算能力方面,而不是存储方面。
因此:
query_string或multi_match查询指向的字段越多,速度就越慢。提高多个字段搜索速度的常用技术是在索引时将它们的值复制到单个字段中,然后在搜索时使用此字段。
请参考ELK文档,该文档建议在copy-to指令的帮助下搜索尽可能少的字段。
在我将查询更改为搜索一个字段后:
一切都运转得很好。
gpnt7bae3#
在我的例子中,我也有一个包含大量文档的索引,这些文档存储了系统运行日志,我搜索了包含所有字段的索引。我使用Java Client API,如下所示:
当我这样修改代码时:
错误消失。