[
https://issues.apache.org/jira/browse/HBASE-16407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15436388#comment-15436388
]
Anoop Sam John commented on HBASE-16407:
----------------------------------------
Thanks for the review.
bq.when will we clear the chunks in the 'chunks' queue? I think the toAdd
condition should be used only to avoid reclaimedChunk.add() but chunks.poll
should happen anyway? There is a chance that the toAdd may be negative at the
first time itself. So no one to remove from chunks.
Ya it can happen that no chunks added from the passed Q. No issue of clear any
way. This Q is the state what we have in HeapMemstoreLAB. We can putBackChunks
method when closing the MSLAB. The chunks are put back to pool. And then we
will throw away this MSLAB object and so all ref instances in it. So the clear
is not having any impact as such.
bq.Should this have a method to deregister things? For clearing things and for
proper RS shutdown.
For RS shutdown the deregister is not needed any way. At RS down, we need to
shutdown the HeapMemoryManager and tuner it that. That is any way happening.
That is why deregister is not having much relevance any way
bq.Should there be a % after which the maxCount should be adjusted? Rather than
just adjusting it every time the value changes?
The % wise decision and adjust decisions happen in HeapMemoryManager. We have
complex logic there. Once the manager decides to change the heap size
distribution btw memstores and block cache, we have to do necessary changes.
Say the tune decided to make the memstore % from 40% to 20%. Say mslab pool
in place and hbase.hregion.memstore.chunkpool.maxsize = 1. Means the
corresponding to the 40% xmx value we might have those many chunks. Now the
total size for memstore is half of old value. We must be removing the
necessary chunks. Even if it is removal of one chunk (maxCapacity reduced by
just 1) we must do the adjustment then it self.. We should not be doing too
many ups and downs of these sizes. But that is the responsibility of the
HeapMemoryManager. and Tuner. It is having all complex algo to decide whether
it is worth doing a heap size distribution change now.
> Handle MemstoreChunkPool size when HeapMemoryManager tunes memory
> -----------------------------------------------------------------
>
> Key: HBASE-16407
> URL: https://issues.apache.org/jira/browse/HBASE-16407
> Project: HBase
> Issue Type: Sub-task
> Reporter: Anoop Sam John
> Assignee: Anoop Sam John
> Fix For: 2.0.0
>
> Attachments: HBASE-16407.patch, HBASE-16407_V2.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
