[
https://issues.apache.org/jira/browse/HBASE-13980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14606774#comment-14606774
]
Abhilash commented on HBASE-13980:
----------------------------------
Currently we ignore few initial periods (while system is restarting and cache
is warming up) and just update our statistics. And for first tuning operation
we assume that last tuner operation was neutral. I guess its a fair estimation
as current stats are in steady state ( atleast for that current memory
distribution). I guess we are out of recursion now :P
> 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)
