Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 22 Apr 2015 00:03:20 +0000 (UTC)
From: "Andrew Purtell (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12819065.1428439433000.68697.1429661000595@Atlassian.JIRA>
In-Reply-To: <JIRA.12819065.1428439433000@Atlassian.JIRA>
References: <JIRA.12819065.1428439433000@Atlassian.JIRA>
 <JIRA.12819065.1428439433448@arcas>
Subject: [jira] [Comment Edited] (HBASE-13420)
 RegionEnvironment.offerExecutionLatency Blocks Threads under Heavy Load
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Andrew Purtell edited comment on HBASE-13420 at 4/22/15 12:02 AM:
------------------------------------------------------------------

bq. I will run a longer comparison tomorrow with 25M keys.
I realized today that 25M keys will take far too long, so here's 5M, which is 5x the amount of data tested yesterday. Test required ~30 minutes to complete each run.

*0.98.12*
||read|| ||update|| ||write||	||
||keys_sec||latency_ms||keys_sec||latency_ms||keys_sec||latency_ms||
|17621.24013|0|655.9144737|7.111842105|3282.815789|2.657894737|

*0.98.13-SNAPSHOT*
||read|| ||update|| ||write||	||
||keys_sec||latency_ms||keys_sec||latency_ms||keys_sec||latency_ms||
|17808.00329|0|655.7697368|7.117763158|3277.661184|2.664473684|

There's some variance, like yesterday where the test showed slightly lower read throughput, today reads are a bit higher and writes are a bit lower. I'd say this change doesn't degrade performance in an obvious way, and shows better performance for the typical case under microbenchmark.


was (Author: apurtell):
> I will run a longer comparison tomorrow with 25M keys.
I realized today that 25M keys will take far too long, so here's 5M, which is 5x the amount of data tested yesterday. Test required ~30 minutes to complete each run.

*0.98.12*
||read|| ||update|| ||write||	||
||keys_sec||latency_ms||keys_sec||latency_ms||keys_sec||latency_ms||
|17621.24013|0|655.9144737|7.111842105|3282.815789|2.657894737|

*0.98.13-SNAPSHOT*
||read|| ||update|| ||write||	||
||keys_sec||latency_ms||keys_sec||latency_ms||keys_sec||latency_ms||
|17808.00329|0|655.7697368|7.117763158|3277.661184|2.664473684|

There's some variance, like yesterday where the test showed slightly lower read throughput, today reads are a bit higher and writes are a bit lower. I'd say this change doesn't degrade performance in an obvious way, and shows better performance for the typical case under microbenchmark.

> RegionEnvironment.offerExecutionLatency Blocks Threads under Heavy Load
> -----------------------------------------------------------------------
>
>                 Key: HBASE-13420
>                 URL: https://issues.apache.org/jira/browse/HBASE-13420
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: John Leach
>            Assignee: Andrew Purtell
>             Fix For: 2.0.0, 1.1.0, 0.98.13, 1.0.2
>
>         Attachments: 1M-0.98.12.svg, 1M-0.98.13-SNAPSHOT.svg, HBASE-13420.patch, HBASE-13420.txt, hbase-13420.tar.gz, offerExecutionLatency.tiff
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> The ArrayBlockingQueue blocks threads for 20s during a performance run focusing on creating numerous small scans.  
> I see a buffer size of (100)
>     private final BlockingQueue<Long> coprocessorTimeNanos = new ArrayBlockingQueue<Long>(
>         LATENCY_BUFFER_SIZE);
> and then I see a drain coming from
>          MetricsRegionWrapperImpl with 45 second executor
>          HRegionMetricsWrapperRunable
>          RegionCoprocessorHost#getCoprocessorExecutionStatistics()   
>          RegionCoprocessorHost#getExecutionLatenciesNanos()
> Am I missing something?


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)