Skip to content

Share serialized settings and mappings between partition definitions #1477

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

Merged
merged 1 commit into from
May 27, 2020

Conversation

jbaiera
Copy link
Member

@jbaiera jbaiera commented May 15, 2020

In situations where large pushdown queries, large mappings, and indices with many shards are combined, we can inflate the driver program memory very quickly as we duplicate the settings and mappings data for each ParititionDefinition we create. This change serializes the settings and mapping data once and shares the immutable state between all PartitionDefinition instances to avoid ballooning memory.

Closes #1476

Copy link
Contributor

@jakelandis jakelandis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jbaiera jbaiera merged commit aca104c into elastic:master May 27, 2020
@jbaiera jbaiera deleted the flyweight-partition-definition branch May 27, 2020 19:35
jbaiera added a commit that referenced this pull request May 27, 2020
…1477)

In situations where large pushdown queries, large mappings, and indices with 
many shards are combined, we can inflate the driver program memory very 
quickly as we duplicate the settings and mappings data for each 
ParititionDefinition we create. This change serializes the settings and mapping 
data once and shares the immutable state between all PartitionDefinition 
instances to avoid ballooning memory.
jbaiera added a commit that referenced this pull request May 27, 2020
…1477)

In situations where large pushdown queries, large mappings, and indices with 
many shards are combined, we can inflate the driver program memory very 
quickly as we duplicate the settings and mappings data for each 
ParititionDefinition we create. This change serializes the settings and mapping 
data once and shares the immutable state between all PartitionDefinition 
instances to avoid ballooning memory.
jbaiera added a commit that referenced this pull request May 27, 2020
…1477)

In situations where large pushdown queries, large mappings, and indices with 
many shards are combined, we can inflate the driver program memory very 
quickly as we duplicate the settings and mappings data for each 
ParititionDefinition we create. This change serializes the settings and mapping 
data once and shares the immutable state between all PartitionDefinition 
instances to avoid ballooning memory.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

OutOfMemoryError for terms query, guidance on max number of terms
2 participants