[
https://issues.apache.org/jira/browse/HBASE-15787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15692275#comment-15692275
]
ramkrishna.s.vasudevan commented on HBASE-15787:
------------------------------------------------
bq.DefaultHeapMemoryTuner dealing with off heap flush count etc.. IMO we should
avoid this.
I think here we are not dealing or tuning the offheap memory. What we are doing
is that we are using those counts to make a better onheap tuning decision. So I
don't think we are making the heap memory tuner to deal with offheap. That is
what I think.
bq.Why we need on heap off heap diff types in FlushType ?
I just need that to know what is the exact flush count I get even when we have
onheap memstore or offheap memstore. May be this enum we can move out of the
tuner? I think I just added some comments over there in the patch to decide on
it.
Actually the decision to increase/decrease memstore size and block size is more
intelligent now. It does in terms terms of smaller steps. Say if we have global
memstore limit as 12G even if we decrease the fraction by 0.1 (say from 0.42 to
0.32 and xmx is 30G) we drastically go down to 9G. But the current code does
not do that way. It still tries to do it with smaller steps.
So when there is an offheap memstore and the reads are more and we need more
block cache space we need to reduce heap memstore limit. In that case we just
try to reduce with the minimum step size.
It is not directly possible to apply something like this
{code}
Blocked flush = blocked flush by heap overhead pressure + 0.75 * blocked flush
by off heap pressure
{code}
We can only indirectly change the step size and in this case we try to make the
step size as less as possible.
One thing is that in case of R/W workload eventually it will settle down in
course of time or as in the current impl if we are not able to take a decision
the current setting are left intact. So I think by all means we are safe.
> 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)
