[
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:
{code}
2016-01-21 17:35:38,699 INFO [main] hbase.IncrementPerformanceTest:
75th=8377534.0, 95th=1.1151665E7, 99th=1.6220691E7
real 1m12.941s
user 1m51.488s
sys 0m53.292s
{code}
A little faster maybe. Here is patch:
{code}
@@ -6951,16 +6951,16 @@ public class HRegion implements HeapSize,
PropagatingConfigurationObserver, Regi
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 {
this.updatesLock.readLock().unlock();
}
// 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 to
+ // the client. Means only way to read-your-own-increment or append is to
come in with an
+ // a 0 increment.
if (writeEntry != null) mvcc.complete(writeEntry);
rowLock.release();
// Request a cache flush if over the limit. Do it outside update lock.
@@ -7095,7 +7096,8 @@ public class HRegion implements HeapSize,
PropagatingConfigurationObserver, Regi
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
{code}
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
(v6.3.4#6332)
