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
},
内存磁盘空间都是足够的。 是什么情况下查询语句会执行过慢呢?
发几个超时的语句吧:
找不到问题的点,求帮助。
但是服务的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左右。找不到问题的点,求帮助。
1 个回复
kennywu76 - Wood
赞同来自:
高cardinality的字段做terms聚合比较容易出现性能问题, 你手动执行很快,很可能是因为命中了Request Cache。 可以先用 POST _cache/clear 清掉缓存再试。