hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiroshi Ikeda (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-15716) HRegion#RegionScannerImpl scannerReadPoints synchronization constrains random read
Date Fri, 01 Jul 2016 08:20:11 GMT

    [ https://issues.apache.org/jira/browse/HBASE-15716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15358632#comment-15358632
] 

Hiroshi Ikeda commented on HBASE-15716:
---------------------------------------

Sorry, I found that getSmallestReadPoint() may go backward when getEntry() is going to adding
a new tail node with an already obsolete read point. In order to keep the consistency between
the methods I should have left the decision of returning the current mvcc read point into
the internal queue. Now I'm thinking:

{code}
  long getSmallestReadPoint() {
    Node head = headRef.get();
    while (true) {
      long refs = head.references;
      if (refs > 0) {
        return head.readPoint;
      }

      Node next = head.next;
      if (next == null) {
        assert refs == 0;

        long mvccReadPoint = getMvccReadPoint();

        if (head.readPoint < mvccReadPoint) {
          next = new Node(mvccReadPoint, 0);
          if (! head.setNextIfAbsent(next)) {
            // The following node is asynchronously set.
            next = head.next;
          }

        } else {
          return head.readPoint;
        }
      }

      assert next != null;

      if (refs < 0 || head.compareAndSetReferences(0, -1)) {
        if (headRef.compareAndSet(head, next)) {
          head = next;
        } else {
          head = headRef.get();
        }
      } // Otherwise head.references is asynchronously changed from 0; Check again.
    }
  }
{code}

Or any better idea? Sorry for bothering you.

> HRegion#RegionScannerImpl scannerReadPoints synchronization constrains random read
> ----------------------------------------------------------------------------------
>
>                 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.implementation.using.ScannerReadPoints.branch-1.patch, 15716.prune.synchronizations.patch,
15716.prune.synchronizations.v3.patch, 15716.prune.synchronizations.v4.patch, 15716.prune.synchronizations.v4.patch,
15716.wip.more_to_be_done.patch, HBASE-15716.branch-1.001.patch, HBASE-15716.branch-1.002.patch,
HBASE-15716.branch-1.003.patch, HBASE-15716.branch-1.004.patch, HBASE-15716.branch-1.005.patch,
ScannerReadPoints.java, 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,
Screen Shot 2016-06-30 at 9.52.52 PM.png, Screen Shot 2016-06-30 at 9.54.08 PM.png, TestScannerReadPoints.java,
before_after.png, current-branch-1.vs.NoSynchronization.vs.Patch.png, hits.png, remove.locks.patch,
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)

Mime
View raw message