[
https://issues.apache.org/jira/browse/SOLR-9658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16897182#comment-16897182
]
Erick Erickson commented on SOLR-9658:
--------------------------------------
Moving over here from 13668:
I'm a little iffy on this. One advantage with filling up the caches to the
limit then keeping it at the limit is that unreasonable limits are more like to
be found during testing. Here's the scenario:
I set up filterCache with a size of 1,000,000
I test for a while with something like fq=timestamp:[NOW-1DAY TO NOW]
I'm indexing a lot and bouncing the server so the cache never grows too large
I put it in production on an unchanging index and generate OOMs.
I've seen this case "in the wild" so it's not entirely theoretical.
Similar situations could occur with aging out entries, it works fine until the
system comes under heavy load where all the cache entries are relatively young.
That said, reducing the memory pressure is always a good thing. Perhaps where
we eventually end up is with some heuristics around dynamically resizing caches
based on memory pressure or aging out cache entries more quickly based on
memory pressure etc., in which case my worries evaporate.
> Caches should have an optional way to clean if idle for 'x' mins
> ----------------------------------------------------------------
>
> Key: SOLR-9658
> URL: https://issues.apache.org/jira/browse/SOLR-9658
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Andrzej Bialecki
> Priority: Major
>
> If a cache is idle for long, it consumes precious memory. It should be
> configurable to clear the cache if it was not accessed for 'x' secs. The
> cache configuration can have an extra config {{maxIdleTime}} . if we wish it
> to the cleaned after 10 mins of inactivity set it to {{maxIdleTime=600}}.
> [~dragonsinth] would it be a solution for the memory leak you mentioned?
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
