hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-9732) Static AtomicLong updated in StoreFileScanner every (re)seek
Date Wed, 09 Oct 2013 06:18:42 GMT

     [ https://issues.apache.org/jira/browse/HBASE-9732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Lars Hofhansl updated HBASE-9732:

    Attachment: 9732-trunk.txt

And the trunk version.
Note that seekCount in StoreFileScanner is no longer final, and it is also not declared as
volatile (as that would again imply read/write barrier just to check whether the reference
is null).
It is up to the (single) test to do the right thing.

I cannot stress enough how bad this is. All StoreFileScanners running inside a RegionServer
content for this one AtomicLong on each seeks just for this this test. Running 3 client that
all filter all rows with a RowFilter (which does a seek to the next row) gives a 10% improvement
with this simple patch.

> Static AtomicLong updated in StoreFileScanner every (re)seek
> ------------------------------------------------------------
>                 Key: HBASE-9732
>                 URL: https://issues.apache.org/jira/browse/HBASE-9732
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Lars Hofhansl
>             Fix For: 0.98.0, 0.94.13, 0.96.1
>         Attachments: 9732-0.94.txt, 9732-trunk.txt
> To verify a single test case, we update a static AtomicLong for *every* seek performed
on a RegionServer. This is especially bad with multiple seeks going on at the same time.
> W.T.F...?
> This penalty should only be incured when we're actually testing and need to count the

This message was sent by Atlassian JIRA

View raw message