我刚打酱油去了,不好意思

elasticsearch查询请求耗时过长

匿名 | 发布于2018年01月08日 | 阅读数:12532

今天出现一次服务请求堆积,好多请求超时的,日志里面记录了查询耗时最长的几个,记录的 es返回给我的took,很多took 特别长 能到536861ms 这么久。
 
但是服务的qps其实很低6-10左右,超时的语句单独拿出来也执行挺快的。
 
es那段时间也没有GC
S0C    S1C    S0U    S1U      EC       EU        OC         OU       PC     PU    YGC     YGCT    FGC    FGCT     GCT   
419392.0 419392.0  0.0   51082.5 3355520.0 298470.4 4194304.0  2803425.4  524288.0 50200.8   1283   70.898   0      0.000   70.898
419392.0 419392.0  0.0   51082.5 3355520.0 300235.5 4194304.0  2803425.4  524288.0 50200.8   1283   70.898   0      0.000   70.898
419392.0 419392.0  0.0   51082.5 3355520.0 321130.9 4194304.0  2803425.4  524288.0 50200.8   1283   70.898   0      0.000   70.898
419392.0 419392.0  0.0   51082.5 3355520.0 348370.7 4194304.0  2803425.4  524288.0 50200.8   1283   70.898   0      0.000   70.898
419392.0 419392.0  0.0   51082.5 3355520.0 378755.9 4194304.0  2803425.4  524288.0 50200.8   1283   70.898   0      0.000   70.898
419392.0 419392.0  0.0   51082.5 3355520.0 407566.7 4194304.0  2803425.4  524288.0 50200.8   1283   70.898   0      0.000   70.898
419392.0 419392.0  0.0   51082.5 3355520.0 419642.6 4194304.0  2803425.4  524288.0 50200.8   1283   70.898   0      0.000   70.898
419392.0 419392.0  0.0   51082.5 3355520.0 442551.1 4194304.0  2803425.4  524288.0 50200.8   1283   70.898   0      0.000   70.898
419392.0 419392.0  0.0   51082.5 3355520.0 460241.0 4194304.0  2803425.4  524288.0 50200.8   1283   70.898   0      0.000   70.898
419392.0 419392.0  0.0   51082.5 3355520.0 464329.2 4194304.0  2803425.4  524288.0 50200.8   1283   70.898   0      0.000   70.898
419392.0 419392.0  0.0   51082.5 3355520.0 472493.6 4194304.0  2803425.4  524288.0 50200.8   1283   70.898   0      0.000   70.898
 
搜索队列的情况:
"search": {
               "threads": 49,
               "queue": 0,
               "active": 0,
               "rejected": 0,
               "largest": 49,
               "completed": 1220972
            },
 
内存磁盘空间都是足够的。  是什么情况下查询语句会执行过慢呢?
发几个超时的语句吧:
{
"size" : 0,
"query" : {
"constant_score" : {
"filter" : {
"bool" : {
"filter" : [ {
"terms" : {
"customId" : [ 50000000207053, 50000000408067, 50000000617433 ]
}
}, {
"term" : {
"evaluateSource" : 2
}
} ]
}
}
}
},
"aggregations" : {
"custom_bucket" : {
"terms" : {
"field" : "customId",
"size" : 10,
"order" : {
"_count" : "desc"
}
},
"aggregations" : {
"score_bucket" : {
"terms" : {
"field" : "evaluateScore",
"size" : 10,
"order" : {
"_count" : "desc"
}
}
}
}
}
}
}
再贴一个问题可能比较大的:
{
"from" : 0,
"size" : 3500,
"query" : {
"query_string" : {
"query" : "+serviceStatus:1 +businessType:9 "
}
},
"sort" : [ {
"compositescore" : {
"order" : "desc"
}
} ]
}
这个size比较大,但是我拿下来去sense里面执行其实也不会耗时那么久,300ms左右。
 
找不到问题的点,求帮助。
 
 
 
 
已邀请:

kennywu76 - Wood

赞同来自:

两层terms聚合嵌套比较容易出现性能问题,需要看一下查询的索引数据总量多大,以及两个聚合的字段,不同的值各有多少(用cardinality aggregtations可以分别探查一下)。
高cardinality的字段做terms聚合比较容易出现性能问题, 你手动执行很快,很可能是因为命中了Request Cache。 可以先用 POST _cache/clear 清掉缓存再试。

要回复问题请先登录注册