[
https://issues.apache.org/jira/browse/HBASE-13082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15181607#comment-15181607
]
Lars Hofhansl commented on HBASE-13082:
---------------------------------------
[[email protected]] [~anoop.hbase], Yep, that's what I suggest
as downside ("risks") above.
Everything that is calling updateReaders will have to wait behind active
StoreScanners. Instead of a lot of huh hah, compactions are delayed until they
can safely finish.
But those would only be StoreScanner open at the time the compaction/flush
tries to finish. So actually my point about delaying compactions potentially
forever is not true. Instead as as soon as the old set or StoreScanners is done
the compaction/flush can proceed and the new Scanner would only see the new
files.
The flush part is concerning, though. Thanks for pointing that out.
That was already the cases before in other situations (like a Scanner that only
encounters deleted Cells with has a Filter that filters most Cells, etc). But
that would not be the case in trunk anymore - just that there we'd disallow the
file to be removed, which is better. There is currently still the checkFlushed
call, which needs a volatile and hence causes a memory barrier.
I'll do some tests. This wasn't meant as an actual patch to be committed, just
wanted to get some feedback. I'm always a fan of simplest code possible.
> Coarsen StoreScanner locks to RegionScanner
> -------------------------------------------
>
> Key: HBASE-13082
> URL: https://issues.apache.org/jira/browse/HBASE-13082
> Project: HBase
> Issue Type: Bug
> Components: Performance, Scanners
> Reporter: Lars Hofhansl
> Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: 13082-test.txt, 13082-v2.txt, 13082-v3.txt,
> 13082-v4.txt, 13082.txt, 13082.txt, CountDownLatch-0.98.txt, HBASE-13082.pdf,
> HBASE-13082_1.pdf, HBASE-13082_12.patch, HBASE-13082_13.patch,
> HBASE-13082_14.patch, HBASE-13082_15.patch, HBASE-13082_16.patch,
> HBASE-13082_17.patch, HBASE-13082_18.patch, HBASE-13082_19.patch,
> HBASE-13082_1_WIP.patch, HBASE-13082_2.pdf, HBASE-13082_2_WIP.patch,
> HBASE-13082_3.patch, HBASE-13082_4.patch, HBASE-13082_9.patch,
> HBASE-13082_9.patch, HBASE-13082_withoutpatch.jpg, HBASE-13082_withpatch.jpg,
> LockVsSynchronized.java, 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)
