[英]Elastic search: Aggregated query very slow
以下匯總查詢過去在10秒內運行。 突然,需要5分鍾以上才能完成。 不知道發生了什么變化。
查詢:
time curl -XGET http://localhost:9200/metric_alias/metrics/_search\?pretty\&routing\=123456 -d '{
"size": 0,
"query": {
"bool": {
"must": [ {
"term": {
"tenantId": 123456
}
},
{
"regexp": {
"metric_name": {
"value": "[^.]*[.][^.]*"
}
}
} ]
}
},
"aggs": {
"metric_name_tokens": {
"terms": {
"field" : "metric_name",
"include": "[^.]*[.][^.]*",
"execution_hint": "map",
"size": 0
}
}
}
}' -o test.out
在使用以下命令清除了字段數據緩存后,我什至嘗試運行查詢
curl -XPOST 'http://localhost:9200/_cache/clear' -d '{ "fielddata": "true" }'
幾個月前,我們更改了這些設置。 不要相信我們正在看到的問題與此相關,因為即使清除了字段數據緩存,它仍然會發生。
indices.breaker.fielddata.limit is set to 85%
indices.fielddata.cache.size is set to 75%
我在查詢運行時記錄了熱線程。我將輸出復制到這里https://gist.github.com/ChandraAddala/180e1d7df9e6f232344c1fe0109b01be
關於如何調試問題的任何想法?
環境:彈性搜索1.7.1。 它是具有125G RAM和40個內核的3節點集群。 ES運行時的堆大小為31G。 metric_alias僅涉及2個索引(一個不再更新)。 大約20GB的數據。 運行查詢時,我看不出CPU和堆使用情況有任何不同。
indices.fielddata.cache.size
和indices.breaker.fielddata.limit
之間的關系很重要。 如果斷路器限制小於緩存大小,則不會驅逐任何數據。 為了使其正常工作, 斷路器的限制必須高於高速緩存的大小 。
indices.breaker.fielddata.limit is set to 85%
indices.fielddata.cache.size is set to 75%
我認為您的indices.breaker.total.limit
未設置,默認為70%
。 因此,即使將indices.breaker.fielddata.limit
設置為85%
indices.breaker.total.limit
限制其功能。
indices.breaker.total.limit
:總斷路器包裝請求斷路器和字段數據斷路器,以確保兩者的組合默認使用的堆空間不超過70%。
嘗試:
indices.breaker.fielddata.limit
增加到>85%
值。 indices.breaker.fielddata.limit
和indices.fielddata.cache.size
減少不到60%
因為為什么單個查詢需要超過60%的堆?
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.