一、问题描述
二、疑问点：
图片示例：
补充：
有点怀疑响应结果中的took值是否准确了，如下图，发现在某一个节点上query阶段和collector阶段的耗时相加和竟然比took要大，不太理解了。
- 同一个Query DSL请求，多次请求，偶现响应时间超大的情况，比如大部分took在100ms以下，但是会存在偶现大于200ms的情况；
- ES集群处于空闲状态，集群配置高（8台实机，每台机器内存182g，40核CPU，1T的SSD），每台机器配置两个Node实例（JVM 30G），每个Node实例一个索引分片，剩余的内存足够索引文件缓存；
- 索引数据量500w+，大小在25G左右；
二、疑问点：
- 采用Profile分析，在took大于200ms的情况，每个shard级别的cost也不高，网上查资料说是profile只会统计Query阶段shard的cost，协调节点merge以及Fetch的过程耗时不会统计，但是集群空闲不会导致这些耗时过高把？
- ES协调节点分发到数据节点的请求是否可以设置超时？（查资料表示不会生效）
图片示例：
- 正常示例[b][/b]
- cost过高示例
补充：
有点怀疑响应结果中的took值是否准确了，如下图，发现在某一个节点上query阶段和collector阶段的耗时相加和竟然比took要大，不太理解了。
4 个回复
zqc0512 - andy zhou
赞同来自: kaiser1992
kaiser1992 - 呆呆的工程师
赞同来自:
laoyang360 - 《一本书讲透Elasticsearch》作者，Elastic认证工程师 [死磕Elasitcsearch]知识星球地址：http://t.cn/RmwM3N9；微信公众号：铭毅天下; 博客：https://elastic.blog.csdn.net
赞同来自:
zmc - ES PAAS、JuiceFS
赞同来自: