[
https://issues.apache.org/jira/browse/HBASE-13980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14606692#comment-14606692
]
Abhilash commented on HBASE-13980:
----------------------------------
The most simple implementation will be that we say we are in steady state if
last (or past few) tuning operations was(were) neutral. If there is sudden
increase in blockedFlushCount and last tuner step was to decrease memstore then
with high probability we can say that this sudden increase was tuner's side
effect.
> Distinguish blockedFlushCount vs unblockedFlushCount when tuning heap memory
> ----------------------------------------------------------------------------
>
> Key: HBASE-13980
> URL: https://issues.apache.org/jira/browse/HBASE-13980
> Project: HBase
> Issue Type: Improvement
> Reporter: Ted Yu
> Assignee: Abhilash
> Priority: Minor
>
> Currently DefaultHeapMemoryTuner doesn't distinguish blockedFlushCount vs
> unblockedFlushCount.
> In its tune() method:
> {code}
> long totalFlushCount = blockedFlushCount+unblockedFlushCount;
> rollingStatsForCacheMisses.insertDataValue(cacheMissCount);
> rollingStatsForFlushes.insertDataValue(totalFlushCount);
> {code}
> Occurrence of blocked flush indicates that upper limit for memstore is not
> sufficient.
> We should either give blockedFlushCount more weight or, take tuning action
> based on blockedFlushCount directly.
> See discussion from tail of HBASE-13876.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
