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

stack commented on HBASE-18294:
-------------------------------

On release note, named the configs to set?

On the patch, couldn't the memstoreSize change... between leaving the 
synchronize block and going in here to do the check?

checkNegativeMemStoreDataSize(size, -memStoreSize.getDataSize());

Copy the datasize to a local variable inside the sync block?

Or nvm... I see that we are passing in the passed-in param, not the data member 
content. In that case, its confusing have param same name as a data member. Can 
lead to confusion.

We are doing this...

1263      public long getMemStoreDataSize() {
1264        return memStoreSize.getDataSize();
1265      }

.. w/o a synchronize. Should there be one? ... Hmm... No, it should be ok. It 
is a volatile read. Ignore.

Interesting, so looking for best region to flush, we'll do data size...

176             (regionToFlush != null && regionToFlush.getMemStoreDataSize() > 
0) ||
177             (bestRegionReplica != null && 
bestRegionReplica.getMemStoreDataSize() > 0));


The data size accounting is just a nice-to-have in the scheme of things? (A 
vestige held over from the back and forth here).

This is right?

91        long getMemStoreSize() {
92          return region.getMemStoreSize();    92          return 
region.getMemStoreDataSize();

... i.e. returing data size when we ask for memstoresize? (We also have a 
getMemStoreDataSize ...)

Did a pass. Looks good to me.





> Reduce global heap pressure: flush based on heap occupancy
> ----------------------------------------------------------
>
>                 Key: HBASE-18294
>                 URL: https://issues.apache.org/jira/browse/HBASE-18294
>             Project: HBase
>          Issue Type: Improvement
>    Affects Versions: 3.0.0
>            Reporter: Eshcar Hillel
>            Assignee: Eshcar Hillel
>            Priority: Major
>             Fix For: 2.0.0-beta-2
>
>         Attachments: HBASE-18294.01.patch, HBASE-18294.01.patch, 
> HBASE-18294.01.patch, HBASE-18294.01.patch, HBASE-18294.01.patch, 
> HBASE-18294.01.patch, HBASE-18294.01.patch, HBASE-18294.02.patch, 
> HBASE-18294.03.patch, HBASE-18294.04.patch, HBASE-18294.05.patch, 
> HBASE-18294.06.patch, HBASE-18294.07.patch, HBASE-18294.07.patch, 
> HBASE-18294.08.patch, HBASE-18294.09.patch, HBASE-18294.10.patch, 
> HBASE-18294.11.patch, HBASE-18294.11.patch, HBASE-18294.12.patch, 
> HBASE-18294.13.patch, HBASE-18294.15.patch, HBASE-18294.16.patch, 
> HBASE-18294.master.01.patch, HBASE-18294.master.01.patch
>
>
> A region is flushed if its memory component exceed a threshold (default size 
> is 128MB).
> A flush policy decides whether to flush a store by comparing the size of the 
> store to another threshold (that can be configured with 
> hbase.hregion.percolumnfamilyflush.size.lower.bound).
> Currently the implementation (in both cases) compares the data size 
> (key-value only) to the threshold where it should compare the heap size 
> (which includes index size, and metadata).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to