[
https://issues.apache.org/jira/browse/SOLR-13579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999344#comment-16999344
]
Andrzej Bialecki edited comment on SOLR-13579 at 12/18/19 4:54 PM:
-------------------------------------------------------------------
A few notes on the soft optimization strategy.
Optimization is performed only when the total limit is not exceeded, because it
may want to not only shrink but also expand cache sizes, thus making a bad
situation worse.
Some background on hitRatio vs cache size: the relationship between cache size
and hit ratio is positive and monotonic, ie. larger cache size leads to a
higher hit ratio (an extreme example would be an unlimited cache that has a
perfect recall because it keeps all items). On the other hand there's a point
where increasing the size yields diminishing returns in terms of higher hit
ratio, if you also consider the cost of the resources it consumes. So there's
likely a sweet spot in the cache size where the hit ratio is still "good
enough" but the resource consumption is minimized. In the proposed patch this
hit ratio threshold is 0.8, which is probably too high for realistic loads
(should we use something like 0.6?).
Hit ratio, by its definition, is an average outcome of several trials on a
stochastic process. For this average to have a desired confidence there's a
minimum number of trials (samples) needed. I'm using a formula of {{0.5 /
sqrt(lookups)}} to determine the minimum number of lookups for a given
confidence level - the default value being 100 lookups for a 5% accuracy. If
there are fewer lookups between adjustments then this means the current hit
ratio cannot be determined with enough confidence and the optimization is
skipped.
Maximum possible adjustments are bounded by a {{maxAdjustRatio}} (by default
2.0). This means that we can grow or shrink the cache at most by this factor,
compared to the initially configured limit. This functionality prevents the
algorithm from balooning or shrinking the cache indefinitely for very busy or
very idle caches.
(This algorithm is in fact a very simple P controller, without the ID factors
(yet :) )).
was (Author: ab):
A few notes on the soft optimization strategy.
Optimization is performed only when the total limit is not exceeded, because it
may want to not only shrink but also expand cache sizes, thus making a bad
situation worse.
Some background on hitRatio vs cache size: the relationship between cache size
and hit ratio is positive and monotonic, ie. larger cache size leads to a
higher hit ratio (an extreme example would be an unlimited cache that has a
perfect recall because it keeps all items). On the other hand there's a point
where increasing the size yields diminishing returns in terms of higher hit
ratio, if you also consider the cost of the resources it consumes. So there's
likely a sweet spot in the cache size where the hit ratio is still "good
enough" but the resource consumption is minimized. In the proposed patch this
hit ratio threshold is 0.8, which is probably too high for realistic loads
(should we use something like 0.6?).
Hit ratio, by its definition, is an average outcome of several trials on a
stochastic process. For this average to have a desired confidence there's a
minimum number of trials (samples) needed. I'm using a formula of {{0.5 /
sqrt(lookups)}} to determine the minimum number of lookups for a given
confidence level - the default value being 100 lookups for a 5% accuracy. If
there are fewer lookups between adjustments then this means the current hit
ratio cannot be determined with enough confidence and the optimization is
skipped.
Maximum possible adjustments are bounded by a {{maxAdjustRatio}} (by default
2.0). This means that we can grow or shrink the cache at most by this factor,
compared to the initially configured limit. This functionality prevents the
algorithm from balooning or shrinking the cache indefinitely for very busy or
very idle caches.
> Create resource management API
> ------------------------------
>
> Key: SOLR-13579
> URL: https://issues.apache.org/jira/browse/SOLR-13579
> Project: Solr
> Issue Type: New Feature
> Reporter: Andrzej Bialecki
> Assignee: Andrzej Bialecki
> Priority: Major
> Attachments: SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch,
> SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch,
> SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Resource management framework API supporting the goals outlined in SOLR-13578.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
