hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-2248) Provide new non-copy mechanism to assure atomic reads in get and scan
Date Fri, 09 Apr 2010 06:09:50 GMT

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

Andrew Purtell commented on HBASE-2248:
---------------------------------------

0.20_pre_durability branch plus HBASE-2248-rr-pre-durability2.txt passes rebalancing for me
but fails TestIdxHBaseCluster consistently.

{noformat}
Testcase: testConcurrentReadWrite took 93.349 sec
	FAILED
nextCount=0, count=2, finalCount=2000
junit.framework.AssertionFailedError: nextCount=0, count=2, finalCount=2000
	at org.apache.hadoop.hbase.TestIdxHBaseCluster.testConcurrentReadWrite(TestIdxHBaseCluster.java:123)

Testcase: testHBaseCluster took 41.074 sec
{noformat}

Before the patch the indexed contrib tests pass on 0.20_pre_durability. 

> Provide new non-copy mechanism to assure atomic reads in get and scan
> ---------------------------------------------------------------------
>
>                 Key: HBASE-2248
>                 URL: https://issues.apache.org/jira/browse/HBASE-2248
>             Project: Hadoop HBase
>          Issue Type: Bug
>    Affects Versions: 0.20.3
>            Reporter: Dave Latham
>            Priority: Blocker
>             Fix For: 0.20.4
>
>         Attachments: HBASE-2248-demonstrate-previous-impl-bugs.patch, HBASE-2248-GetsAsScans3.patch,
HBASE-2248-rr-alpha3.txt, HBASE-2248-rr-pre-durability2.txt, hbase-2248.gc, HBASE-2248.patch,
hbase-2248.txt, readownwrites-lost.2.patch, readownwrites-lost.patch, Screen shot 2010-02-23
at 10.33.38 AM.png, threads.txt
>
>
> HBASE-2037 introduced a new MemStoreScanner which triggers a ConcurrentSkipListMap.buildFromSorted
clone of the memstore and snapshot when starting a scan.
> After upgrading to 0.20.3, we noticed a big slowdown in our use of short scans.  Some
of our data repesent a time series.   The data is stored in time series order, MR jobs often
insert/update new data at the end of the series, and queries usually have to pick up some
or all of the series.  These are often scans of 0-100 rows at a time.  To load one page, we'll
observe about 20 such scans being triggered concurrently, and they take 2 seconds to complete.
 Doing a thread dump of a region server shows many threads in ConcurrentSkipListMap.biuldFromSorted
which traverses the entire map of key values to copy it.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message