[
https://issues.apache.org/jira/browse/SOLR-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15643091#comment-15643091
]
Shalin Shekhar Mangar commented on SOLR-9633:
---------------------------------------------
The size based eviction logic in markAndSweep method is moved to
markAndSweepByCacheSize -- there are no logic changes when only item size is
used for eviction. But if maxRamMB is configured then we use the
markAndSweepByRamSize method which evicts by making two passes over the cache
and a sort. After these changes, the FastLRUCache behaves differently than
LRUCache. Instead of supporting both size and maxRamMB and evicting based on
both limits, the FastLRUCache supports either size or maxRamMB but not both.
This is also because I couldn't figure out a way to evict by ram as efficiently
as we do today by size.
We could support both size and ram together by evicting by size first and then
fall back to the expensive two pass eviction based on ram.
> Limit FastLRUCache by RAM Usage
> -------------------------------
>
> Key: SOLR-9633
> URL: https://issues.apache.org/jira/browse/SOLR-9633
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Shalin Shekhar Mangar
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9633.patch
>
>
> SOLR-7372 added a maxRamMB parameter to LRUCache to evict items based on
> memory usage. That helps with the query result cache but not with the filter
> cache which defaults to FastLRUCache. This issue intends to add the same
> feature to FastLRUCache.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
