Estimate segment field usages #112760
Merged
Estimate segment field usages #112760
Conversation
This file contains 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
dnhatn
force-pushed
the
field-infos-usage
branch
from
e3e5128
to
481f542
Compare
dnhatn
added
v8.16.0
auto-backport-and-merge
:StorageEngine/Mapping
dnhatn
requested review from
pxsalehi,
henningandersen,
jpountz and
martijnvg
|
Pinging @elastic/es-storage-engine (Team:StorageEngine) |
jpountz
approved these changes
Sep 11, 2024
| if (fi.hasNorms()) { | ||
| usages++; | ||
| } | ||
| if (fi.hasVectors()) { |
There was a problem hiding this comment.
We can probably skip term vectors: their memory usage does not scale with the number of fields (like stored fields).
There was a problem hiding this comment.
Yes, I have pushed 5cc4f35 to remove this.
|
The change looks fine. I wonder if we need to go this granular though, or if we should assume that all fields that exist have an index (either terms, points or vectors) and doc values. Some fields may only have doc values, but then it's fine if we overestimate a bit? |
|
Thanks, Adrien. I considered this option, but it would require overestimating the current estimate by 20% in all cases, which might prevent us from running 2GB instances. I'll merge this PR and discuss the follow-up changes for serverless. If we find a different solution, I'll revert this change. |
dnhatn
added a commit
to dnhatn/elasticsearch
that referenced
this pull request
Sep 11, 2024
We have introduced a new memory estimation method in serverless, based on the number of segments and the fields within them. This new approach works well overall, but it still falls short in cases where most fields are used more than once - for example, in both doc_values and postings, or doc_values and points. This change exposes the total usage of fields in segments, allowing us to adjust the memory estimate for these cases.
💚 Backport successful
|
elasticsearchmachine
pushed a commit
that referenced
this pull request
Sep 12, 2024
We have introduced a new memory estimation method in serverless, based on the number of segments and the fields within them. This new approach works well overall, but it still falls short in cases where most fields are used more than once - for example, in both doc_values and postings, or doc_values and points. This change exposes the total usage of fields in segments, allowing us to adjust the memory estimate for these cases.
v1v
added a commit
to v1v/elasticsearch
that referenced
this pull request
Sep 12, 2024
…tion-ironbank-ubi * upstream/main: (302 commits) Deduplicate BucketOrder when deserializing (elastic#112707) Introduce test utils for ingest pipelines (elastic#112733) [Test] Account for auto-repairing for shard gen file (elastic#112778) Do not throw in task enqueued by CancellableRunner (elastic#112780) Mute org.elasticsearch.script.StatsSummaryTests testEqualsAndHashCode elastic#112439 Mute org.elasticsearch.repositories.blobstore.testkit.integrity.RepositoryVerifyIntegrityIT testTransportException elastic#112779 Use a dedicated test executor in MockTransportService (elastic#112748) Estimate segment field usages (elastic#112760) (Doc+) Inference Pipeline ignores Mapping Analyzers (elastic#112522) Fix verifyVersions task (elastic#112765) (Doc+) Terminating Exit Codes (elastic#112530) (Doc+) CAT Nodes default columns (elastic#112715) [DOCS] Augment installation warnings (elastic#112756) Mute org.elasticsearch.repositories.blobstore.testkit.integrity.RepositoryVerifyIntegrityIT testCorruption elastic#112769 Bump Elasticsearch to a minimum of JDK 21 (elastic#112252) ESQL: Compute support for filtering ungrouped aggs (elastic#112717) Bump Elasticsearch version to 9.0.0 (elastic#112570) add CDR related data streams to kibana_system priviliges (elastic#112655) Support widening of numeric types in union-types (elastic#112610) Introduce data stream options and failure store configuration classes (elastic#109515) ...
davidkyle
pushed a commit
that referenced
this pull request
Sep 12, 2024
We have introduced a new memory estimation method in serverless, based on the number of segments and the fields within them. This new approach works well overall, but it still falls short in cases where most fields are used more than once - for example, in both doc_values and postings, or doc_values and points. This change exposes the total usage of fields in segments, allowing us to adjust the memory estimate for these cases.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
We have introduced a new memory estimation method in serverless, based on the number of segments and the fields within them. This new approach works well overall, but it still falls short in cases where most fields are used more than once - for example, in both doc_values and postings, or doc_values and points. This change exposes the total usage of fields in segments, allowing us to adjust the memory estimate for these cases.