You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Andrzej Bialecki (Jira)" <ji...@apache.org> on 2019/12/18 16:55:00 UTC
[jira] [Comment Edited] (SOLR-13579) Create resource management API
[ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org