hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anoop Sam John (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-15787) Change the flush related heuristics to work with offheap size configured
Date Mon, 21 Nov 2016 06:54:59 GMT

    [ https://issues.apache.org/jira/browse/HBASE-15787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15682720#comment-15682720
] 

Anoop Sam John commented on HBASE-15787:
----------------------------------------

DefaultHeapMemoryTuner dealing with off heap flush count etc.. IMO we should avoid  this..
 Got it why we are doing so.. In case of off heap MSLAB, the forced flushes might be because
of global off heap memstore size pressure or by global heap memstore overhead.  When it is
because of the latter, we need to do some thing in the Heap memory tuner (If possible)  Any
way we pass this as blocked flush count.   So when we have the flushes because of heap memory
overhead pressure, we account that any way so as to get some help from the tuner. (possible
up))  But when there are no pressure from heap size, and have lack of space in L1 cache, tuner
should down the memstore % and give that space for L1 cache.. That is ur intent.. I agree
to this.   And any way we need to consider flushes because of off heap pressure also.. After
all these counts are used to check whether we have R/W workload and what extend. 
May be we can do some sort of math and pass blocked flushes, unblocked flush with out separation
of heap/off heap
Blocked flush = blocked flush by heap overhead pressure +  0.75 * blocked flush by off heap
pressure
Same with unblocked flush count

Why we need on heap off heap diff types in FlushType ?


> Change the flush related heuristics to work with offheap size configured
> ------------------------------------------------------------------------
>
>                 Key: HBASE-15787
>                 URL: https://issues.apache.org/jira/browse/HBASE-15787
>             Project: HBase
>          Issue Type: Sub-task
>          Components: regionserver
>            Reporter: ramkrishna.s.vasudevan
>            Assignee: ramkrishna.s.vasudevan
>             Fix For: 2.0.0
>
>         Attachments: HBASE-15787.patch, HBASE-15787_1.patch
>
>
> With offheap MSLAB in place we may have to change the flush related heuristics to work
with offheap size configured rather than the java heap size.
> Since we now have clear seperation of the memstore data size and memstore heap size,
for offheap memstore
> -> Decide if the global.offheap.memstore.size is breached for blocking updates and
force flushes. 
> -> If the onheap global.memstore.size is breached (due to heap overhead) even then
block updates and force flushes.
> -> The global.memstore.size.lower.limit is now by default 95% of the global.memstore.size.
So now we apply this 95% on the global.offheap.memstore.size and also on global.memstore.size
(as it was done for onheap case).
> -> We will have new FlushTypes introduced
> {code}
>   ABOVE_ONHEAP_LOWER_MARK, /* happens due to lower mark breach of onheap memstore settings
>                               An offheap memstore can even breach the onheap_lower_mark*/
>   ABOVE_ONHEAP_HIGHER_MARK,/* happens due to higher mark breach of onheap memstore settings
>                               An offheap memstore can even breach the onheap_higher_mark*/
>   ABOVE_OFFHEAP_LOWER_MARK,/* happens due to lower mark breach of offheap memstore settings*/
>   ABOVE_OFFHEAP_HIGHER_MARK;
> {code}
> -> regionServerAccounting does all the accounting.
> -> HeapMemoryTuner is what is litte tricky here. First thing to note is that at no
point it will try to increase or decrease the global.offheap.memstore.size. If there is a
heap pressure then it will try to increase the memstore heap limit. 
> In case of offheap memstore there is always a chance that the heap pressure does not
increase. In that case we could ideally decrease the heap limit for memstore. The current
logic of heapmemory tuner is such that things will naturally settle down. But on discussion
what we thought is let us include the flush count that happens due to offheap pressure but
give that a lesser weightage and thus ensure that the initial decrease on memstore heap limit
does not happen. Currently that fraction is set as 0.5. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message