[
https://issues.apache.org/jira/browse/HBASE-15716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15261563#comment-15261563
]
Hiroshi Ikeda commented on HBASE-15716:
---------------------------------------
Quite strictly speaking, there is a very very small bug :P
When the collection scannerReadPoints is empty and
{code}
+ private long calculateReadPoint(final IsolationLevel level) {
+ long readPoint = getReadpoint(level);
{code}
and mvcc's readpoint goes forward, with the smallest readpoint going forward,
and
{code}
+ while (true) {
+ scannerReadPoints.put(this, readPoint);
{code}
and then, the smallest readpoint goes back.
By the way, I think the difficult point is that the mvcc's readpoint can move
without our control. HRegion should have an independent instance variable to
follow the readpoint under synchronization or something.
Moreover, the collection scannerReadPoints have too much information, and we
should remove entries severally in order to GC obsolete scanner readers. It is
enough for entries to have a readpoint and a reference count, with each scanner
reader having a reference to the entry. It is not even needed to register when
IsolationLevel.READ_UNCOMMITTED.
I think ConcurrentLinkedQueue, AtomicReferenceFieldUpdater, and ReentrantLock
(tryLock to follow the mvcc's readpoint with best-effot) are useful to reduce
conflict between threads.
> HRegion#RegionScannerImpl scannerReadPoints synchronization costs
> -----------------------------------------------------------------
>
> Key: HBASE-15716
> URL: https://issues.apache.org/jira/browse/HBASE-15716
> Project: HBase
> Issue Type: Bug
> Components: Performance
> Reporter: stack
> Assignee: stack
> Attachments: 15716.prune.synchronizations.patch,
> 15716.prune.synchronizations.v3.patch, 15716.prune.synchronizations.v4.patch,
> Screen Shot 2016-04-26 at 2.05.45 PM.png, Screen Shot 2016-04-26 at 2.06.14
> PM.png, Screen Shot 2016-04-26 at 2.07.06 PM.png, Screen Shot 2016-04-26 at
> 2.25.26 PM.png, Screen Shot 2016-04-26 at 6.02.29 PM.png, Screen Shot
> 2016-04-27 at 9.49.35 AM.png,
> current-branch-1.vs.NoSynchronization.vs.Patch.png, hits.png,
> remove_cslm.patch
>
>
> Here is a [~lhofhansl] special.
> When we construct the region scanner, we get our read point and then store it
> with the scanner instance in a Region scoped CSLM. This is done under a
> synchronize on the CSLM.
> This synchronize on a region-scoped Map creating region scanners is the
> outstanding point of lock contention according to flight recorder (My work
> load is workload c, random reads).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
