[
https://issues.apache.org/jira/browse/HBASE-13082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991079#comment-14991079
]
ramkrishna.s.vasudevan commented on HBASE-13082:
------------------------------------------------
bq. The way region replicas work is that they rely on having a high TTL for the
hfiles so that even if primary replica compacts the file away and moves the
file to the archive directory, the secondary replica will be able to still read
from the archive location.
Is it? So is that because my tests are running in the Windows environment (I
mean my Junits) this issue occurs. But one thing is that after this patch
comes in - the Secondary replica does not close the reader when an update
happens on the secondary region. I have not yet run this secondary replica
thing in my Linux box still but I found even in linux some junits failed due to
this behaviour.
{code}
- // let the archive util decide if we should archive or delete the files
- LOG.debug("Removing store files after compaction...");
- for (StoreFile compactedFile : compactedFiles) {
- compactedFile.closeReader(true);
- }
- if (removeFiles) {
- this.fs.removeStoreFiles(this.getColumnFamilyName(), compactedFiles);
- }
{code}
bq.The volatile check is still a memory fence barrier similar to the lock
although much less expensive. Were you able to profile this implementation
similar to Lars' numbers above?
Yes, I did some basic PE tool runs. I got 6 to 7% improvement. This is the case
where it is pure read (scan workload on the server side with filterAll enabled)
and there were no compactions or flushes. I can do some more tests on a bigger
load and I think the main advantage of this patch is going to be with scans
rather than gets if am not wrong.
The other advantage of this patch is that because we use the older files only
after compactions we avoid the reset and reseek on those new compacted files
and other files already in heap. Discussing with Anoop, even for flushes we can
ensure that instead of reset we can only allow the heap to be changed and
ensure only the new flushed file we do a seek to the current key the scaner was
at which the memstore was flushed. But that can be done as a later improvement.
Thanks Enis for your reviews.
> Coarsen StoreScanner locks to RegionScanner
> -------------------------------------------
>
> Key: HBASE-13082
> URL: https://issues.apache.org/jira/browse/HBASE-13082
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Assignee: ramkrishna.s.vasudevan
> Attachments: 13082-test.txt, 13082-v2.txt, 13082-v3.txt,
> 13082-v4.txt, 13082.txt, 13082.txt, HBASE-13082.pdf, HBASE-13082_1.pdf,
> HBASE-13082_1_WIP.patch, HBASE-13082_2_WIP.patch, HBASE-13082_3.patch,
> HBASE-13082_4.patch, HBASE-13082_9.patch, HBASE-13082_9.patch, gc.png,
> gc.png, gc.png, hits.png, next.png, next.png
>
>
> Continuing where HBASE-10015 left of.
> We can avoid locking (and memory fencing) inside StoreScanner by deferring to
> the lock already held by the RegionScanner.
> In tests this shows quite a scan improvement and reduced CPU (the fences make
> the cores wait for memory fetches).
> There are some drawbacks too:
> * All calls to RegionScanner need to be remain synchronized
> * Implementors of coprocessors need to be diligent in following the locking
> contract. For example Phoenix does not lock RegionScanner.nextRaw() and
> required in the documentation (not picking on Phoenix, this one is my fault
> as I told them it's OK)
> * possible starving of flushes and compaction with heavy read load.
> RegionScanner operations would keep getting the locks and the
> flushes/compactions would not be able finalize the set of files.
> I'll have a patch soon.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
