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搜索的并发性。
索引是只读的。该索引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搜索的并发性。
1 个回复
locatelli
赞同来自:
这里会不会有其它的因素?另外 shard 有多大?有没有比较过不同大小 shard 的性能?