[
https://issues.apache.org/jira/browse/HBASE-13082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-13082:
--------------------------
Attachment: gc.png
next.png
I ran small test w/ this patch applied on 1.0 branch.
Had ten processes each with ten clients each running on one machine doing
random scans against another machine hosting a regionserver. Each scan was of
1000 rows. The dataset was 100M rows made of ten columns of data where the data
was zipfian between 0 and 8k; so ten random colums w/ max of 8k. Its PE
scan1000.
First, no surprise, we are pegged at about 650% of CPU when about 1600
available (TODO). Otherwise, the graphs show a hike in scan next ops of a nice
10-15% with patch applied. More interesting is the GC profile. With the patch
applied, we do way less GC (looking at patch, locks are creating lots of
objects -- haven't looked..)
> 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
> Attachments: 13082-test.txt, 13082.txt, 13082.txt, gc.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)
