绊脚石乃是进身之阶。

elasticsearch检索聚合慢得离奇啊?

Elasticsearch | 作者 runc | 发布于2017年09月25日 | 阅读数:5697

2.5到3亿的数据量,涵盖400个索引,rest查询的方式比trasport要快,rest的方式(head插件)只需要3-7s左右,而transport要慢,大概50s左右,查询条件绝对一致,考虑到rest的方式不支持太多索引,使用了通配符的方式,但返回的数据量差不多,但性能为何相差如此之大呢?
已邀请:

kennywu76 - Wood

赞同来自: novia ybtsdst

正确使用的情况下,transport和rest的查询速度几乎是一样的,不会因为协议的差异导致这么巨大的查询耗时差异。多半是理解和使用方法上存在问题。
 
这个差异是否可以反复复现? 如果是可以反复复现的问题,试一下先做以下两点检查:
  1. 确认下rest和transport查询到索引数量是一样的,这点可以从response里检查hits的shards数量得到。
  2. 如果查询的shards数量完全一致,那么从response里拿一下查询耗费的时间,对比看是否差别很大。做这个确认的原因是,transport client实例化的时候,有一个node discovery的过程,特别是开了sniff的情况下,如果配置的结点和sniff到的结点ip,有不存在,或者网络无法通达的情况,需要等到timeout,才会完成实例化过程,这种情况下耗时看起来会比较长。

 最好贴一下restful的查询的完整dsl, 以及transport查询的代码。

novia - 1&0

赞同来自:

从描述来看,transport耗费的时间不应该只是在查询上,是不是实例化时间也计算在内呢?

runc

赞同来自:

首先感谢@kennywu76 wood大哥,去掉sniff配置,响应速度有所提升,但reponse的time耗时还是时快时慢,下面贴一下相关dsl和更详细的描述:
 
es 
单jvm配置:
-Xms8g
-Xmx8g
-Xmn512m
 
集群配置:
6台虚机,16c 32G的配置
 
rest的dsl信息:
 
{
"from" : 0,
"size" : 15,
"query" : {
"bool" : {
"must" : [
{
"query_string" : {
"query" : "*",
"fields" : [ ],
"use_dis_max" : true,
"tie_breaker" : 0.0,
"default_operator" : "or",
"auto_generate_phrase_queries" : false,
"max_determined_states" : 10000,
"enable_position_increment" : true,
"fuzziness" : "AUTO",
"fuzzy_prefix_length" : 0,
"fuzzy_max_expansions" : 50,
"phrase_slop" : 0,
"escape" : false,
"split_on_whitespace" : true,
"boost" : 1.0
}
}
],
"filter" : [
{
"range" : {
"@timestamp" : {
"from" : 1506392981000,
"to" : 1506394781000,
"include_lower" : true,
"include_upper" : true,
"boost" : 1.0
}
}
}
],
"disable_coord" : false,
"adjust_pure_negative" : true,
"boost" : 1.0
}
},
"sort" : [
{
"@timestamp" : {
"order" : "desc"
}
}
],
"highlight" : {
"pre_tags" : [
"<strongclass='stack_hightlight'>"
],
"post_tags" : [
"<class='stack_hightlight'strong>"
],
"fragment_size" : 2147483647,
"highlight_query" : {
"match" : {
"message" : {
"query" : "*",
"operator" : "OR",
"prefix_length" : 0,
"max_expansions" : 50,
"fuzzy_transpositions" : true,
"lenient" : false,
"zero_terms_query" : "NONE",
"boost" : 1.0
}
}
},
"fields" : {
"*" : { }
}
},
"ext" : { }
}

 
rest的方式返回局部信息:
 
"took":13321,"timed_out":false,"_shards":{"total":2280,"successful":2280,"failed":0},"hits":{"total":230430583,"max_score":1.0 ....}
执行10次,基本耗时在12-13s左右,
 
但是transport的方式,是偶尔很快,有时很慢,快的时候3-7s就能出结果,慢的时候30-50s左右。

runc

赞同来自:

这个大致的应用部署结构是:
                                               es1,es2
web1
             <=> (vip)机器   < =>       es3,es4
web2                              
                                                es5,es6
 
web机器通过tcp 9300 连接vip负载均衡机器到和es集群进行通讯的,是什么原因导致集群处理请求如此不稳定呢?

要回复问题请先登录注册