要不要也来分享分享一下啊

segment合并之后,发现有些慢查询更慢了。

Elasticsearch | 作者 zhq | 发布于2019年10月19日 | 阅读数:1627

ES 7.1。
索引是只读的。该索引3个primary shard,1个replica shard,分布在6台data node(8core, 16G, local SSD)。
测试期间,CPU/Mem/IO等资源都没瓶颈。
 
同样的query语句,用esrally测试(1 client,200 iterations)发现 99th 和 100th percentile latency更慢了。
segment merge之前:
*          50th     90th       99th       100th
round1  120.7    142.963   203.774  214.143
round2 120.378 146.769   182.482  197.598
round3 122.226 140.465   165.919   216.171

force merge成1个segment之后:
*          50th      90th     99th       100th
round1  122.988 150.65   275.859  1121.07
round2 120.6     158.247 296.168   1174.59
round3 112.151   145.831  303.111    1107.62
 
query语句rewrite之后是:一个DocValuesFieldExistsQuery和多个TermQuery。
profile结果显示主要耗时在DocValuesFieldExistsQuery部分,匹配fieldExists的数据确实比较多。请问会不会是单segment太大,导致docvalue在MMap Page In/Out的耗时太长?看到MMap里是顺序存储,一个field的docvalue过大,是不是比较容易触发换出?
另外,一个search request在单shard内是单线程search所有segments吗?如果不是,合并之后,是否降低了shard内segments搜索的并发性。

 
已邀请:

locatelli

赞同来自:

单segment 理论上应该会提高搜索性能。
这里会不会有其它的因素?另外 shard 有多大?有没有比较过不同大小 shard 的性能?

要回复问题请先登录注册