New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Carry over version map size to prevent excessive resizing #27516
Conversation
Today we create a new concurrent hash map everytime we refresh the internal reader. Under defaults this isn't much of a deal but once the refresh interval is set to `-1` these maps grow quite large and it can have a significant impact on indexing throughput. Under low memory situations this can cause up to 2x slowdown. This change carries over the map size as the initial capacity wich will be auto-adjusted once indexing stops.
here is a benchmark that I ran with and without the change and
note: baseline is with the change |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great finding! I left one minor comment but LGTM.
@@ -117,7 +117,7 @@ public void afterRefresh(boolean didRefresh) throws IOException { | |||
// case. This is because we assign new maps (in beforeRefresh) slightly before Lucene actually flushes any segments for the | |||
// reopen, and so any concurrent indexing requests can still sneak in a few additions to that current map that are in fact reflected | |||
// in the previous reader. We don't touch tombstones here: they expire on their own index.gc_deletes timeframe: | |||
maps = new Maps(maps.current, ConcurrentCollections.<BytesRef,VersionValue>newConcurrentMapWithAggressiveConcurrency()); | |||
maps = new Maps(maps.current, Collections.emptyMap()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm probably lacking the larger context here but is it ok to change the implementation class from ConcurrentHashMap
to HashMap
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah it's an immutable map and we should never ever modify it too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Good catch!
Agreed it does. |
Today we create a new concurrent hash map everytime we refresh the internal reader. Under defaults this isn't much of a deal but once the refresh interval is set to `-1` these maps grow quite large and it can have a significant impact on indexing throughput. Under low memory situations this can cause up to 2x slowdown. This change carries over the map size as the initial capacity wich will be auto-adjusted once indexing stops. Closes #20498
Today we create a new concurrent hash map everytime we refresh the internal reader. Under defaults this isn't much of a deal but once the refresh interval is set to `-1` these maps grow quite large and it can have a significant impact on indexing throughput. Under low memory situations this can cause up to 2x slowdown. This change carries over the map size as the initial capacity wich will be auto-adjusted once indexing stops. Closes #20498
Today we create a new concurrent hash map everytime we refresh the internal reader. Under defaults this isn't much of a deal but once the refresh interval is set to `-1` these maps grow quite large and it can have a significant impact on indexing throughput. Under low memory situations this can cause up to 2x slowdown. This change carries over the map size as the initial capacity wich will be auto-adjusted once indexing stops. Closes #20498
Today we create a new concurrent hash map everytime we refresh the internal reader. Under defaults this isn't much of a deal but once the refresh interval is set to `-1` these maps grow quite large and it can have a significant impact on indexing throughput. Under low memory situations this can cause up to 2x slowdown. This change carries over the map size as the initial capacity wich will be auto-adjusted once indexing stops. Closes #20498
* es/master: (38 commits) Backport wait_for_initialiazing_shards to cluster health API Carry over version map size to prevent excessive resizing (#27516) Fix scroll query with a sort that is a prefix of the index sort (#27498) Delete shard store files before restoring a snapshot (#27476) Replace `delimited_payload_filter` by `delimited_payload` (#26625) CURRENT should not be a -SNAPSHOT version if build.snapshot is false (#27512) Fix merging of _meta field (#27352) Remove unused method (#27508) unmuted test, this has been fixed by #27397 Consolidate version numbering semantics (#27397) Add wait_for_no_initializing_shards to cluster health API (#27489) [TEST] use routing partition size based on the max routing shards of the second split Adjust CombinedDeletionPolicy for multiple commits (#27456) Update composite-aggregation.asciidoc Deprecate `levenstein` in favor of `levenshtein` (#27409) Automatically prepare indices for splitting (#27451) Validate `op_type` for `_create` (#27483) Minor ShapeBuilder cleanup muted test Decouple nio constructs from the tcp transport (#27484) ...
* es/6.x: (30 commits) Add wait_for_no_initializing_shards to cluster health API (#27489) Carry over version map size to prevent excessive resizing (#27516) Fix scroll query with a sort that is a prefix of the index sort (#27498) Delete shard store files before restoring a snapshot (#27476) CURRENT should not be a -SNAPSHOT version if build.snapshot is false (#27512) Fix merging of _meta field (#27352) test: do not run percolator query builder bwc test against 5.x versions Remove unused method (#27508) Consolidate version numbering semantics (#27397) Adjust CombinedDeletionPolicy for multiple commits (#27456) Minor ShapeBuilder cleanup [GEO] Deprecate ShapeBuilders and decouple geojson parse logic Improve docs for split API in 6.1/6.x (#27504) test: use correct pre 6.0.0-alpha1 format Update composite-aggregation.asciidoc Deprecate `levenstein` in favor of `levenshtein` (#27409) Decouple nio constructs from the tcp transport (#27484) Bump version from 6.1 to 6.2 Fix whitespace in Security.java Tighten which classes can exit ...
This is great. I wonder if we should reset the map during synced flush to make sure we free resources when we go idle (there are other options, but I think this is the simplest). |
Today we carry on the size of the live version map to ensure that we minimze rehashing. Yet, once we are idle or we can issue a sync-commit we can resize it to defaults to free up memory. Relates to elastic#27516
Today we carry on the size of the live version map to ensure that we minimze rehashing. Yet, once we are idle or we can issue a sync-commit we can resize it to defaults to free up memory. Relates to #27516
Today we carry on the size of the live version map to ensure that we minimze rehashing. Yet, once we are idle or we can issue a sync-commit we can resize it to defaults to free up memory. Relates to #27516
Today we carry on the size of the live version map to ensure that we minimze rehashing. Yet, once we are idle or we can issue a sync-commit we can resize it to defaults to free up memory. Relates to #27516
Today we carry on the size of the live version map to ensure that we minimze rehashing. Yet, once we are idle or we can issue a sync-commit we can resize it to defaults to free up memory. Relates to #27516
Today we carry on the size of the live version map to ensure that we minimze rehashing. Yet, once we are idle or we can issue a sync-commit we can resize it to defaults to free up memory. Relates to #27516
Today we create a new concurrent hash map everytime we refresh
the internal reader. Under defaults this isn't much of a deal but
once the refresh interval is set to
-1
these maps grow quite largeand it can have a significant impact on indexing throughput. Under low
memory situations this can cause up to 2x slowdown. This change carries
over the map size as the initial capacity wich will be auto-adjusted once
indexing stops.
Closes #20498