[
https://issues.apache.org/jira/browse/HBASE-15102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15097370#comment-15097370
]
Ashu Pachauri commented on HBASE-15102:
---------------------------------------
ok..I will play :)
Line 279: step = 10, currMemstore = 50, currBlockCache = 50, minMemstore = 42
Line 280: step = 10, newMemstore = 50 -10 = 40 , currMemstore = 50,
currBlockcache = 50, minMemstore = 42
Now, you enter the block
Line 282: step = 10, newMemstore = 42 = minMemstore, currMemstore = 50,
currBlockCache = 50
Line 283: step = 8 (currMemstore - newMemstore) , newMemstore = 42,
currMemstore=50, currBlockcache = 50
Line 285: step = 8, newMemstore = 42, newBlockCache = 50 + 8 (currBlockCache +
step), currMemstore = 50 = currBlockcache
newMemstore + newBlockcache = 42 + 58 = 100 = 50 + 50 = currMemstore +
currBlockcache
> HeapMemoryTuner can "overtune" memstore size and suddenly drop it into
> blocking zone
> ------------------------------------------------------------------------------------
>
> Key: HBASE-15102
> URL: https://issues.apache.org/jira/browse/HBASE-15102
> Project: HBase
> Issue Type: Bug
> Components: regionserver
> Affects Versions: 2.0.0, 1.2.0, 1.3.0, 1.2.1
> Reporter: Ashu Pachauri
> Assignee: Ashu Pachauri
> Priority: Critical
> Attachments: HBASE-15102-V0.patch
>
>
> DefaultHeapMemoryTuner often resets the maximum step size for tuning to 8% of
> total heap size. Often, when the size of memstore is to be decreased while
> tuning, the 8% tuning can suddenly drop the memstore size below the low water
> mark of the previous memstore size (which could potentially be the used size
> of the memstore)
> This is problematic because suddenly it blocks all the updates by suddenly
> causing a situation where memstore used size is above high water mark. This
> has a very bad performance impact on an otherwise fine HBase cluster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
