[
https://issues.apache.org/jira/browse/SOLR-13790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrzej Bialecki updated SOLR-13790:
------------------------------------
Attachment: SOLR-13790.patch
> LRUStatsCache size explosion
> ----------------------------
>
> Key: SOLR-13790
> URL: https://issues.apache.org/jira/browse/SOLR-13790
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 7.7.2, 8.2, 8.3
> Reporter: Andrzej Bialecki
> Assignee: Andrzej Bialecki
> Priority: Critical
> Fix For: 7.7.3, 8.3
>
> Attachments: SOLR-13790.patch
>
>
> On a sizeable cluster with multi-shard multi-replica collections, when
> {{LRUStatsCache}} was in use we encountered excessive memory usage, which
> consequently led to severe performance problems.
> On a closer examination of the heapdumps it became apparent that when
> {{LRUStatsCache.addToPerShardTermStats}} is called it creates instances of
> {{FastLRUCache}} using the passed {{shard}} argument - however, the value of
> this argument is not a simple shard name but instead it's a randomly ordered
> list of ALL replica URLs for this shard.
> As a result, due to the combinatoric number of possible keys, over time the
> map in {{LRUStatsCache.perShardTemStats}} grew to contain ~2 mln entries...
> The fix seems to be simply to extract the shard name and cache using this
> name instead of the full string value of the {{shard}} parameter. Existing
> unit tests also need much improvement.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
