Make Cache More Memory Efficient #77546
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
No need to keep counters per segment when we only use them in aggregate. Also, removed a few spots of using needless indirection by making segments reference the cache itself directly and saved a bunch of empty maps for idle caches on e.g. rarely used indices.
original-brownbear
added
>non-issue
:Core/Infra/Core
Collaborator
|
Pinging @elastic/es-core-infra (Team:Core/Infra) |
grcevski
reviewed
Sep 10, 2021
|
|
||
| private boolean promote(Entry<K, V> entry, long now) { | ||
| boolean promoted = true; | ||
| private void promote(Entry<K, V> entry, long now) { |
Contributor
There was a problem hiding this comment.
Just a minor thought here, splitting this method to avoid double locking may not be worth the complexity. ReentrantLock will check if a lock is already owned by the same thread and avoid the compare and set operation. There's still going to be a volatile int field increment, but it should be relatively inexpensive.
Contributor
Author
There was a problem hiding this comment.
Fair point :) reverted that part of the change
grcevski
approved these changes
Sep 13, 2021
Contributor
grcevski
left a comment
grcevski
left a comment
There was a problem hiding this comment.
Looks good to me. LGTM!
Contributor
Author
|
Thanks Nikola! |
original-brownbear
added a commit
to original-brownbear/elasticsearch
that referenced
this pull request
Sep 13, 2021
No need to keep counters per segment when we only use them in aggregate. Also, removed a few spots of using needless indirection by making segments reference the cache itself directly and saved a bunch of empty maps for idle caches on e.g. rarely used indices.
original-brownbear
added a commit
that referenced
this pull request
Sep 13, 2021
No need to keep counters per segment when we only use them in aggregate. Also, removed a few spots of using needless indirection by making segments reference the cache itself directly and saved a bunch of empty maps for idle caches on e.g. rarely used indices.
97 tasks
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.
Found the memory savings while looking at some heap dumps and added the indirection savings on top:
No need to keep counters per segment when we only use them in aggregate.
Also, removed a few spots of using needless indirection by making
segments reference the cache itself directly and saved a bunch of empty maps
for idle caches on e.g. rarely used indices.
This halves the size of an empty cache (I think it was ~110k to ~60k in the empty case) which isn't a massive saving but also not entirely irrelevant when thinking about large index counts per node (+ it speeds up tests a little by saving 10M+ on heap during most internal cluster tests from all kinds of empty caches :)).