[
https://issues.apache.org/jira/browse/SOLR-10205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15902487#comment-15902487
]
Ben Manes commented on SOLR-10205:
----------------------------------
For writes you might prefer to use an atomic computation instead of a racy
get-compute-put. The stampeding writers will cause a storm of removal
notifications indicating the value was replaced. I think that would result in
more frequently needing to free and acquire slots in the bank. This would
reduce I/O costs as well, of course. Caffeine performs this by using a
lock-free lookup that falls back to a computeIfAbsent, so that a hit won't
thrash on locks if the entry is present.
> Evaluate and reduce BlockCache store failures
> ---------------------------------------------
>
> Key: SOLR-10205
> URL: https://issues.apache.org/jira/browse/SOLR-10205
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Yonik Seeley
> Assignee: Yonik Seeley
> Fix For: 6.5, master (7.0)
>
> Attachments: cache_performance_test.txt, SOLR-10205.patch,
> SOLR-10205.patch, SOLR-10205.patch
>
>
> The BlockCache is written such that requests to cache a block
> (BlockCache.store call) can fail, making caching less effective. We should
> evaluate the impact of this storage failure and potentially reduce the number
> of storage failures.
> The implementation reserves a single block of memory. In store, a block of
> memory is allocated, and then a pointer is inserted into the underling map.
> A block is only freed when the underlying map evicts the map entry.
> This means that when two store() operations are called concurrently (even
> under low load), one can fail. This is made worse by the fact that
> concurrent maps typically tend to amortize the cost of eviction over many
> keys (i.e. the actual size of the map can grow beyond the configured maximum
> number of entries... both the older ConcurrentLinkedHashMap and newer
> Caffeine do this). When this is the case, store() won't be able to find a
> free block of memory, even if there aren't any other concurrently operating
> stores.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
