[
https://issues.apache.org/jira/browse/HBASE-25975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17362206#comment-17362206
]
Andrew Kyle Purtell edited comment on HBASE-25975 at 6/12/21, 1:06 AM:
-----------------------------------------------------------------------
As of
[c4cf83ce|https://github.com/apache/hbase/pull/3360/commits/c4cf83ce469a029c6d37ecfe4e39a006bcc7376e]
I have something that passes TestHRegion and at least the first group of
hbase-server tests (Tests run: 1083, Failures: 0, Errors: 0, Skipped: 4). I got
bored and hit ^C after a couple of hours somewhere in the second group.
Attached as [^HBASE-25975-c4cf83ce.pdf] is a simple benchmark of the
implementation as of this commit. The test creates an HRegion, constructs the
requisite number of Puts for the test iteration, starts up the desired number
of threads waiting on a countdown latch, then releases the latch. The threads
submit their batch of Puts as quickly as possible, 1000 times. Between each run
the region is flushed and compacted. The total execution time is measured from
latch release until the last thread terminates. Contended and uncontended cases
are measured. An average time in milliseconds per operation is calculated by
dividing the running time by the number of operations each thread attempts in
parallel. Overhead is calculated by taking the measurements from the 0%
contention case and subtracting a baseline measurement of the same activity
without any changes applied. It is encouraging that even at this early stage
for most cases the measured overhead is less than 1 millisecond per operation.
Where that was not the case is highlighted by numbers in red. The overhead is
flat with respect to number of active real CPU threads and appears to amortize
over batches. There are obvious optimization opportunities for the large batch
high contention cases, though.
was (Author: apurtell):
As of
[c4cf83ce|https://github.com/apache/hbase/pull/3360/commits/c4cf83ce469a029c6d37ecfe4e39a006bcc7376e]
I have something that passes TestHRegion and at least the first group of
hbase-server tests (Tests run: 1083, Failures: 0, Errors: 0, Skipped: 4). I got
bored and hit ^C after a couple of hours somewhere in the second group.
Attached as [^HBASE-25975-c4cf83ce.pdf] is a simple benchmark of the
implementation as of this commit. The test creates an HRegion, constructs the
requisite number of Puts, starts up the desired number of threads waiting on a
countdown latch, then releases the latch. The threads submit their batch of
Puts as quickly as possible, 1000 times. The total execution time is measured
from latch release until the last thread terminates. An average time in
milliseconds per operation is calculated by dividing the running time by the
number of operations each thread attempts in parallel. Overhead is calculated
by taking the measurements from the 0% contention case and subtracting a
baseline measurement of the same activity without any changes applied. It is
encouraging that even at this early stage for most cases the measured overhead
is less than 1 millisecond per operation. Where that was not the case is
highlighted by numbers in red. The overhead is flat with respect to number of
active real CPU threads and appears to amortize over batches. There are obvious
optimization opportunities for the large batch high contention cases, though.
> Row commit sequencer
> --------------------
>
> Key: HBASE-25975
> URL: https://issues.apache.org/jira/browse/HBASE-25975
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver
> Reporter: Andrew Kyle Purtell
> Assignee: Andrew Kyle Purtell
> Priority: Major
> Fix For: 3.0.0-alpha-1, 2.5.0
>
> Attachments: HBASE-25975-c4cf83ce.pdf
>
>
> Use a row commit sequencer in HRegion to ensure that only the operations that
> mutate disjoint sets of rows are able to commit within the same clock tick.
> This maintains the invariant that more than one mutation to a given row will
> never be committed in the same clock tick.
> Callers will first acquire row locks for the row(s) the pending mutation will
> mutate. Then they will use RowCommitSequencer.getRowSequence to ensure that
> the set of rows about to be mutated do not overlap with those for any other
> pending mutations in the current clock tick. If an overlap is identified,
> getRowSequence will yield and loop until there is no longer an overlap and
> the caller's pending mutation can succeed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
