[
https://issues.apache.org/jira/browse/HBASE-10263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13863838#comment-13863838
]
Feng Honghua commented on HBASE-10263:
--------------------------------------
Thanks [~ndimiduk] for the careful review :-)
bq.Evictions happen on a background thread. Filling the cache and then
immediately checking the eviction count results in a race between the current
thread and the eviction thread; thus this is very likely a flakey test on our
over-extended build machines. In the above block, the call to cacheBlock() will
only notify the eviction thread, not force eviction.
What you said is correct for the real usage scenario of LruBlockCache where the
evictionThread flag is implicitly true when constructing the LruBlockCache
object, that way a background eviction thread is created to do the eviction
job, but it's *not* the case for this newly added unit test: to be able to
verify the evict effect of the new configuration/preemptive-mode as quickly as
possible without worrying how long to sleep or introducing other kind of
synchronization overhead, I disabled the background eviction thread when
constructing the LruBlockCache object for this unit test case, this way the
eviction will be triggered immediately and synchronously within the
cache.cacheBlock call when the cache size exceeds the acceptable cache size.
{code}LruBlockCache cache = new LruBlockCache(maxSize, blockSize,
false...){code}
> make LruBlockCache single/multi/in-memory ratio user-configurable and provide
> preemptive mode for in-memory type block
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: HBASE-10263
> URL: https://issues.apache.org/jira/browse/HBASE-10263
> Project: HBase
> Issue Type: Improvement
> Components: io
> Reporter: Feng Honghua
> Assignee: Feng Honghua
> Attachments: HBASE-10263-trunk_v0.patch, HBASE-10263-trunk_v1.patch
>
>
> currently the single/multi/in-memory ratio in LruBlockCache is hardcoded
> 1:2:1, which can lead to somewhat counter-intuition behavior for some user
> scenario where in-memory table's read performance is much worse than ordinary
> table when two tables' data size is almost equal and larger than
> regionserver's cache size (we ever did some such experiment and verified that
> in-memory table random read performance is two times worse than ordinary
> table).
> this patch fixes above issue and provides:
> 1. make single/multi/in-memory ratio user-configurable
> 2. provide a configurable switch which can make in-memory block preemptive,
> by preemptive means when this switch is on in-memory block can kick out any
> ordinary block to make room until no ordinary block, when this switch is off
> (by default) the behavior is the same as previous, using
> single/multi/in-memory ratio to determine evicting.
> by default, above two changes are both off and the behavior keeps the same as
> before applying this patch. it's client/user's choice to determine whether or
> which behavior to use by enabling one of these two enhancements.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
