无论才能、知识多么卓著,如果缺乏热情,则无异纸上画饼充饥,无补于事。

es查询速度方差很大

Elasticsearch | 作者 wyl0706 | 发布于2017年09月27日 | 阅读数:4680

用ES进行查询的时候,整体速度是非常快的,但是我们的Indices大小小于内存的情况下:3台node,每个node有128G内存,堆大小31G,剩下的给lucene做缓存;index大小104G,shard 12片。
但是如图,我们的使用相同的查询请求(请求语句一模一样,但是value不一样),查询时间方差非常大。特别是有1%的影响时间在200+ms,在我们的应用场景这是很难接受的。
不知道这有可能是什么样的原因?
1.png
已邀请:

kennywu76 - Wood^Trip.com

赞同来自: rockybean wanges

测试结果要和测试方法结合起来进行解读, 这里至少缺少了以下信息:
1. 测试是从集群冷启动开始的,还是已经预热过后再做的。
2. 测试的并发线程数量, qps有多高。
3. 测试过程中ES结点的资源消耗情况,cpu usage%, load average,  thread pool active/queue/reject等等。
 
如果集群是从冷启动开始做测试, 数据有个逐步warm up的过程,初始的查询可能因为需要访问磁盘,耗时会比较长(特别是机械磁盘)。 
如果测试的并发线程数过高,qps过高,可能压到了集群处理极限, 当search thread全部繁忙的时候,可能会有请求在search queue里排队,增加了部分请求的时延。

kennywu76 - Wood^Trip.com

赞同来自: laoyang360

@wyl0706 另外,你说你们用的查询都一样,只是value不一样。 请问查询是什么类型的查询? 能给个范例吗?  
 
因为我想到我们线上之前遇到过的一个问题,是关于wildcard查询的,查询的性能刚好就和value的长度有关系。 如果用了wildcard query,特别要注意这一点。

rockybean - Elastic Certified Engineer, ElasticStack Fans,公众号:ElasticTalk

赞同来自:

你可以在查询的时候在后面增加preference参数来限定查询的shard,来先确认下是不是查询不同shard导致的
 
GET [index_name]/_search?preference=_shards:0|_primary
然后调用下 force_merge 看看合并segment后是否会好转
 
我之前的确遇到过主副分片查询速度不一致的情况,但没有确认最终原因……

wyl0706 - 90后IT男

赞同来自:

这些数据是在生产环境运行一天得到的,所以应该不存在冷启动问题。qps在300-400,ES负载不是很高,详情请看附件

kennywu76 - Wood^Trip.com

赞同来自:

@wyl0706 你抓去这些性能数据的时候,集群在线上服务吗? 有搜索流量么? 从你给的stats看,当前集群基本是空闲的。
 
最好是有监控系统,将这些数据图表化,看起来更容易。 比如我们将threads_pool图表化后,看起来这样:

Elasticsearch_Cloud.jpg


Elasticsearch_Cloud1.jpg

 
这样比较容易帮忙判别问题。

要回复问题请先登录注册