You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Andrzej Bialecki (JIRA)" <ji...@apache.org> on 2019/07/15 19:56:00 UTC
[jira] [Comment Edited] (SOLR-13558) Allow dynamic resizing of
SolrCache-s
[ https://issues.apache.org/jira/browse/SOLR-13558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16885559#comment-16885559 ]
Andrzej Bialecki edited comment on SOLR-13558 at 7/15/19 7:55 PM:
-------------------------------------------------------------------
This patch implements the dynamic modification of limits of all Solr cache implementations, using an API similar to the one proposed in the parent issue.
Some notes:
* FastLRUCache has been modified to support both size and maxRamMB limits simultaneously.
* LRUCache eviction has been modified to allow evicting multiple entries when the size limit is changed.
* LFUCache doesn't support {{maxRamMB}} limit, unlike all other cache implementations. This can be added relatively easily, but probably in a separate issue.
* more unit tests are needed to verify the behavior of caches when other parameters are changed (acceptableSize, minLimit, cleanupThread, etc)
was (Author: ab):
This patch implements dynamic modification of limits of all Solr cache implementations, using an API similar to the one proposed in the parent issue.
> Allow dynamic resizing of SolrCache-s
> -------------------------------------
>
> Key: SOLR-13558
> URL: https://issues.apache.org/jira/browse/SOLR-13558
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Andrzej Bialecki
> Assignee: Andrzej Bialecki
> Priority: Major
> Attachments: SOLR-13558.patch
>
>
> Currently SolrCache limits are configured statically and can't be reconfigured without cache re-initialization (core reload), which is costly. In some situations it would help to be able to dynamically re-size the cache based on the resource contention (such as the total heap size used for caching across all cores in a node).
> Each cache implementation already knows how to evict its entries when it runs into configured limits - what is missing is to expose this mechanism using a uniform API.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org