Skip to content

Commit 74c4dc1

Browse files
Avoid walking the complete list of search contexts on shard creation (elastic#123855)
This I found in the many-shards benchmark during some manual testing. Creating indices slows down measurably when there's concurrent searches going on. Interestingly enough, the bulk of the cost is coming from this hook. This makes sense to some extend because the map can quickly grow to a massive size as it scales as O(shards_searched_on_average * concurrent_searches) and a CHM generally is anything but cheap to iterate over.
1 parent 7f4769b commit 74c4dc1

File tree

1 file changed

+2
-1
lines changed

1 file changed

+2
-1
lines changed

server/src/main/java/org/elasticsearch/search/SearchService.java

+2-1
Original file line numberDiff line numberDiff line change
@@ -30,6 +30,7 @@
3030
import org.elasticsearch.action.support.TransportActions;
3131
import org.elasticsearch.cluster.ClusterState;
3232
import org.elasticsearch.cluster.metadata.IndexNameExpressionResolver.ResolvedExpression;
33+
import org.elasticsearch.cluster.routing.RecoverySource;
3334
import org.elasticsearch.cluster.routing.ShardRouting;
3435
import org.elasticsearch.cluster.service.ClusterService;
3536
import org.elasticsearch.common.CheckedSupplier;
@@ -511,7 +512,7 @@ public void beforeIndexShardCreated(ShardRouting routing, Settings indexSettings
511512
// to stop searches to restore full availability as fast as possible. A known scenario here is that we lost connection to master
512513
// or master(s) were restarted.
513514
assert routing.initializing();
514-
if (routing.isRelocationTarget() == false) {
515+
if (routing.isRelocationTarget() == false && routing.recoverySource() != RecoverySource.EmptyStoreRecoverySource.INSTANCE) {
515516
freeAllContextsForShard(routing.shardId());
516517
}
517518
}

0 commit comments

Comments
 (0)