详情
4节点集群:每个28GB RAM,4个核心,2个512GB SSD 2 - 主/数据 2-仅数据
使用ElasticSearch 1.5.2(这可能是一个自修复以来的错误吗?)
摘要
我正在尝试调试我们看到的一些问题,我们的群集对查询响应缓慢。它并不总是那么慢,所以我们怀疑它只是一个规模问题(坐在20亿个文件之下)。
然而,在对索引进行了一些讨论之后,我注意到我们的排序占用了99%的响应时间。以下是我一直在运行的两个示例查询。第一个是排序,第二个是没有。
进行排序
此调用需要45秒到60秒以上(我们的nginx服务器超时设置为60秒,并且它超时很多)并且只返回644个文档。这意味着它似乎需要45秒以上才能对仅有644个项目进行排序
POST /backup/entity/_search?routing=3f9d219f-6eef-4880-ad5f-0494492c2fd6
{
"from": 0,
"size": 100,
"sort": [
{
"entityName.raw": {
"order": "asc"
}
}
],
"highlight": {
"pre_tags": [
"<span class=\"highlighter\">"
],
"post_tags": [
"</span>"
],
"fields": {
"entityName": {},
"friendlyUrl": {},
"sentBy": {}
},
"require_field_match": true
},
"query": {
"bool": {
"must": [
{
"term": {
"serviceId": "3f9d219f-6eef-4880-ad5f-0494492c2fd6"
}
},
{
"term": {
"subscriptionType": 1
}
},
{
"terms": {
"entityType": [
2
]
}
}
],
"should": []
}
}
}
不分拣
此调用另一方面返回100-200ms。相同的644文档,只是没有排序。
POST /backup/entity/_search?routing=3f9d219f-6eef-4880-ad5f-0494492c2fd6
{
"from": 0,
"size": 100,
"highlight": {
"pre_tags": [
"<span class=\"highlighter\">"
],
"post_tags": [
"</span>"
],
"fields": {
"entityName": {},
"friendlyUrl": {},
"sentBy": {}
},
"require_field_match": true
},
"query": {
"bool": {
"must": [
{
"term": {
"serviceId": "3f9d219f-6eef-4880-ad5f-0494492c2fd6"
}
},
{
"term": {
"subscriptionType": 1
}
},
{
"terms": {
"entityType": [
2
]
}
}
],
"should": []
}
}
}
似乎很难相信在这些文档上运行排序算法确实需要很长时间。即使我同时检查所有4个节点,CPU和JVM在任何给定时间都不会超过60%的使用率,因此它不像某台机器在所有45秒以上计算100%CPU的排序。还有其他事情要发生在这里。