[
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)
