Trigger refresh when shard becomes search active #96321
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
martijnvg force-pushed the tsdb/trigger_refresh_when_becoming_search_active branch from a22b725 to b82b9f5 Compare 
| (accidentally pushed 'ready for review' on this PR... too many open browser tabs) |
martijnvg added the :Distributed Indexing/Engine 
martijnvg force-pushed the tsdb/trigger_refresh_when_becoming_search_active branch 4 times, most recently from 0b75a31 to b24857e Compare …ot register refresh listener.
martijnvg force-pushed the tsdb/trigger_refresh_when_becoming_search_active branch from b24857e to 266aa36 Compare | Did a quick benchmark run to see what the impact this change has using the k8s query benchmark (it tests performance of queries on search idle shards). Depending on the query a 15% to a 75% reduction in query time has been observed: |
…_becoming_search_active
of adding a new method to IndexShard
martijnvg commented May 31, 2023
server/src/main/java/org/elasticsearch/index/shard/IndexShard.java Outdated Show resolved Hide resolved
…_becoming_search_active
updated the testScheduledRefresh(...) test.
martijnvg commented Jun 1, 2023
| // wait until the thread-pool has moved the timestamp otherwise we can't assert on this below | ||
| assertBusy(() -> assertThat(primary.getThreadPool().relativeTimeInMillis(), greaterThan(lastSearchAccess))); | ||
| CountDownLatch latch = new CountDownLatch(10); | ||
| for (int i = 0; i < 10; i++) { |
There was a problem hiding this comment.
Because makeShardSearchActive(...) now triggers a refresh, we can no longer invoke this method many times without a refresh to happen. Before this was possible in this test and then just invoke scheduleRefresh(...) and all the listeners were invoked.
| * <code>true</code> if the listener was registered to wait for a refresh. | ||
| */ | ||
| public final void awaitShardSearchActive(Consumer<Boolean> listener) { | ||
| public final void makeShardSearchActive(Consumer<Boolean> listener) { |
There was a problem hiding this comment.
I'd probably call this ensureShardSearchActive, though not too important.
| }); | ||
| // TODO: maybe just invoke getEngine().maybeRefresh(...) here? | ||
| // (schedule refresh does a few more things that I don't is necessary here?) | ||
| scheduledRefresh(); |
There was a problem hiding this comment.
I think it will work fine, but one problem with maybeRefresh is that it will not provoke a refresh if there is an ongoing one. But there is no certainty that another ongoing refresh will contain the location. However, such a refresh would have to be an explicit one. I find the risk small and regardless an improvement over current state.
I think we can switch to maybeRefresh instead, though I'd like to check that pendingRefreshLocation is still location then, i.e.:
Suggested change
| scheduledRefresh(); | |
| if (pendingRefreshLocation.get() == location) { | |
| getEngine().maybeRefresh(); | |
| } |
both to handle racy cases and the case where there are no more refresh listener slots.
elasticsearchmachine added Team:Distributed (Obsolete) 
| Hi @martijnvg, I've created a changelog YAML for you. |
| Pinging @elastic/es-analytics-geo (Team:Analytics) |
| Pinging @elastic/es-distributed (Team:Distributed) |
…_becoming_search_active
…_becoming_search_active
henningandersen approved these changes Jun 9, 2023
| }); | ||
| // trigger a refresh to avoid waiting for scheduledRefresh(...) to be invoked from index level refresh scheduler. | ||
| // (The if statement should avoid doing an additional refresh if scheduled refresh was invoked between getting | ||
| // the current refresh location and adding a refresh listener.) |
There was a problem hiding this comment.
In particular, addRefreshListener might have performed the refresh already in edge cases.
server/src/test/java/org/elasticsearch/index/shard/IndexShardTests.java Outdated Show resolved Hide resolved
Co-authored-by: Henning Andersen <33268011+henningandersen@users.noreply.github.com>
| @elasticmachine update branch |
…_becoming_search_active
…_becoming_search_active
…_becoming_search_active
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge. Suggestion cannot be applied right now. Please check back later.
This change invokes
Engine#maybeRefresh()when a shard is search-idle and becomes search-active inIndexShard#ensureShardSearchActive(...)(used to be namedwaitShardSearchActive(...)).Prior to this change shard level search execution is idle until the schedule refresh has been execute. This includes the time it takes for the refresh to be scheduled (which is a full second). This unnecessarily increases the query time of a search request.
Closes #95544