You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "Lars Hofhansl (JIRA)" <ji...@apache.org> on 2017/12/23 18:35:00 UTC
[jira] [Resolved] (HBASE-15453) [Performance] Considering reverting
HBASE-10015 - reinstate synchronized in StoreScanner
[ https://issues.apache.org/jira/browse/HBASE-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lars Hofhansl resolved HBASE-15453.
-----------------------------------
Resolution: Won't Fix
Lemme just close. In 1.3+ it's not an issue anyway (the need to synchronize is gone there)
> [Performance] Considering reverting HBASE-10015 - reinstate synchronized in StoreScanner
> ----------------------------------------------------------------------------------------
>
> Key: HBASE-15453
> URL: https://issues.apache.org/jira/browse/HBASE-15453
> Project: HBase
> Issue Type: Improvement
> Components: Performance
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Priority: Critical
> Attachments: 15453-0.98.txt
>
>
> In HBASE-10015 back then I found that intrinsic locks (synchronized) in StoreScanner are slower that explicit locks.
> I was surprised by this. To make sure I added a simple perf test and many folks ran it on their machines. All found that explicit locks were faster.
> Now... I just ran that test again. On the latest JDK8 I find that now the intrinsic locks are significantly faster:
> (OpenJDK Runtime Environment (build 1.8.0_72-b15))
> Explicit locks:
> 10 runs mean:2223.6 sigma:72.29412147609237
> Intrinsic locks:
> 10 runs mean:1865.3 sigma:32.63755505548784
> I confirmed the same with timing some Phoenix scans. We can save a bunch of time by changing this back
> Arrghhh... So maybe it's time to revert this now...?
> (Note that in trunk due to [~ram_krish]'s work, we do not lock in StoreScanner anymore)
> I'll attach the perf test and a patch that changes lock to synchronized, if some folks could run this on 0.98, that'd be great.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
Re: [jira] [Resolved] (HBASE-15453) [Performance] Considering
reverting HBASE-10015 - reinstate synchronized in StoreScanner
Posted by Gaurav Agarwal <ga...@gmail.com>.
On Dec 24, 2017 00:05, "Lars Hofhansl (JIRA)" <ji...@apache.org> wrote:
>
> [ https://issues.apache.org/jira/browse/HBASE-15453?page=
> com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Lars Hofhansl resolved HBASE-15453.
> -----------------------------------
> Resolution: Won't Fix
>
> Lemme just close. In 1.3+ it's not an issue anyway (the need to
> synchronize is gone there)
>
> > [Performance] Considering reverting HBASE-10015 - reinstate synchronized
> in StoreScanner
> > ------------------------------------------------------------
> ----------------------------
> >
> > Key: HBASE-15453
> > URL: https://issues.apache.org/jira/browse/HBASE-15453
> > Project: HBase
> > Issue Type: Improvement
> > Components: Performance
> > Reporter: Lars Hofhansl
> > Assignee: Lars Hofhansl
> > Priority: Critical
> > Attachments: 15453-0.98.txt
> >
> >
> > In HBASE-10015 back then I found that intrinsic locks (synchronized) in
> StoreScanner are slower that explicit locks.
> > I was surprised by this. To make sure I added a simple perf test and
> many folks ran it on their machines. All found that explicit locks were
> faster.
> > Now... I just ran that test again. On the latest JDK8 I find that now
> the intrinsic locks are significantly faster:
> > (OpenJDK Runtime Environment (build 1.8.0_72-b15))
> > Explicit locks:
> > 10 runs mean:2223.6 sigma:72.29412147609237
> > Intrinsic locks:
> > 10 runs mean:1865.3 sigma:32.63755505548784
> > I confirmed the same with timing some Phoenix scans. We can save a bunch
> of time by changing this back
> > Arrghhh... So maybe it's time to revert this now...?
> > (Note that in trunk due to [~ram_krish]'s work, we do not lock in
> StoreScanner anymore)
> > I'll attach the perf test and a patch that changes lock to synchronized,
> if some folks could run this on 0.98, that'd be great.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.14#64029)
>
Re: [jira] [Resolved] (HBASE-15453) [Performance] Considering
reverting HBASE-10015 - reinstate synchronized in StoreScanner
Posted by Gaurav Agarwal <ga...@gmail.com>.
User
On Dec 24, 2017 00:05, "Lars Hofhansl (JIRA)" <ji...@apache.org> wrote:
[ https://issues.apache.org/jira/browse/HBASE-15453?page=
com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lars Hofhansl resolved HBASE-15453.
-----------------------------------
Resolution: Won't Fix
Lemme just close. In 1.3+ it's not an issue anyway (the need to synchronize
is gone there)
> [Performance] Considering reverting HBASE-10015 - reinstate synchronized
in StoreScanner
> ------------------------------------------------------------
----------------------------
>
> Key: HBASE-15453
> URL: https://issues.apache.org/jira/browse/HBASE-15453
> Project: HBase
> Issue Type: Improvement
> Components: Performance
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Priority: Critical
> Attachments: 15453-0.98.txt
>
>
> In HBASE-10015 back then I found that intrinsic locks (synchronized) in
StoreScanner are slower that explicit locks.
> I was surprised by this. To make sure I added a simple perf test and many
folks ran it on their machines. All found that explicit locks were faster.
> Now... I just ran that test again. On the latest JDK8 I find that now the
intrinsic locks are significantly faster:
> (OpenJDK Runtime Environment (build 1.8.0_72-b15))
> Explicit locks:
> 10 runs mean:2223.6 sigma:72.29412147609237
> Intrinsic locks:
> 10 runs mean:1865.3 sigma:32.63755505548784
> I confirmed the same with timing some Phoenix scans. We can save a bunch
of time by changing this back
> Arrghhh... So maybe it's time to revert this now...?
> (Note that in trunk due to [~ram_krish]'s work, we do not lock in
StoreScanner anymore)
> I'll attach the perf test and a patch that changes lock to synchronized,
if some folks could run this on 0.98, that'd be great.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)