hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-15082) Fix merge of MVCC and SequenceID performance regression
Date Fri, 22 Jan 2016 01:42:39 GMT

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

stack commented on HBASE-15082:

Ok. I hacked up the branch-1 trick in here and it didn't make that much difference:

2016-01-21 17:35:38,699 INFO  [main] hbase.IncrementPerformanceTest: 75th=8377534.0, 95th=1.1151665E7,

real    1m12.941s
user    1m51.488s
sys     0m53.292s

A little faster maybe. Here is patch:

@@ -6951,16 +6951,16 @@ public class HRegion implements HeapSize, PropagatingConfigurationObserver,
           accumulatedResultSize +=
               applyToMemstore(e.getKey(), e.getValue(), true, false, sequenceId);
-        mvcc.completeAndWait(writeEntry);
-        // Clear walKey so don't complete for second time in finally below.
-        writeEntry = null;
       } finally {
       // If results is null, then client asked that we not return the calculated results.
       return results !=  null? Result.create(results): null;
     } finally {
-      // Call complete rather than completeAndWait because we probably had error if walKey
!= null
+      // Call complete always, even on success. doDelta is doing a Get READ_UNCOMMITTED when
it goes
+      // to get current value under an exclusive lock so no need so no need to wait to return
+      // the client. Means only way to read-your-own-increment or append is to come in with
+      // a 0 increment.
       if (writeEntry != null) mvcc.complete(writeEntry);
       // Request a cache flush if over the limit.  Do it outside update lock.
@@ -7095,7 +7096,8 @@ public class HRegion implements HeapSize, PropagatingConfigurationObserver,
     byte [] columnFamily = store.getFamily().getName();
     List<Cell> toApply = new ArrayList<Cell>(deltas.size());
     // Get previous values for all columns in this family.
-    List<Cell> currentValues = get(mutation, store, deltas, null/*DEFAULT*/,
+    List<Cell> currentValues = get(mutation, store, deltas,
+        IsolationLevel.READ_UNCOMMITTED/*Presumes exclusive lock on row*/,
         op == Operation.INCREMENT? ((Increment)mutation).getTimeRange(): null);
     // Iterate the input columns and update existing values if they were found, otherwise
     // add new column initialized to the delta amount

We do READ_UNCOMMITTED while we have the exclusive row lock and then on the end we go back
to the client after doing mvcc.complete, not mvcc.completeAndWait. To read current value with
a Get you must do a READ_UNCOMMITTED or just do an Increment with a zero value and read the
returned valued. This 'trick' gets a little more involved for append and then more so again
for checkAnd*

Probably should go under a flag. Going to put aside for now as an avenue to explore later.
I may have the performance I need without having to do any weird tricks.

> Fix merge of MVCC and SequenceID performance regression
> -------------------------------------------------------
>                 Key: HBASE-15082
>                 URL: https://issues.apache.org/jira/browse/HBASE-15082
>             Project: HBase
>          Issue Type: Sub-task
>          Components: Performance
>            Reporter: stack
>            Assignee: stack
>            Priority: Critical
>             Fix For: 2.0.0, 1.3.0
>         Attachments: 15082.patch, 15082v10.patch, 15082v12.patch, 15082v13.patch, 15082v14.patch,
15082v14.patch, 15082v15.patch, 15082v16.patch, 15082v2.patch, 15082v2.txt, 15082v3.txt, 15082v4.patch,
15082v5.patch, 15082v6.patch, 15082v7.patch, 15082v8.patch
> This is general fix for increments (appends, checkAnd*) perf-regression identified in
the parent issue. HBASE-15031 has a narrow fix for branch-1.1 and branch-1.0.

This message was sent by Atlassian JIRA

View raw message