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

Lars Hofhansl updated HBASE-10015:
----------------------------------

    Attachment: TestLoad.java

Test code. This is some crap extracted from various tests, don't judge me on 
that code.. I will deny that I've ever written that.
Use it with TestLoad <tableName>. It will create and seed the table if needed.
Then it runs the scan tests 5 times (after a prime round) and calculates mean 
and standard deviation.

Did I mention that this is hack? :)

For the record, I see a 2-3x scan speed improvement on both OpenJDK7 on a 
old'ish 2 core machine as well as with Oracle JDK6 on a 12 core machine. In 
both cases the scan is from a single client only.


> Major performance improvement: Avoid synchronization in StoreScanner
> --------------------------------------------------------------------
>
>                 Key: HBASE-10015
>                 URL: https://issues.apache.org/jira/browse/HBASE-10015
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Lars Hofhansl
>         Attachments: 10015-0.94.txt, TestLoad.java
>
>
> Did some more profiling (this time with a sampling profiler) and 
> StoreScanner.peek() showed up a lot in the samples. At first that was 
> surprising, but peek is synchronized, so it seems a lot of the sync'ing cost 
> is eaten there.
> It seems the only reason we have to synchronize all these methods is because 
> a concurrent flush or compaction can change the scanner stack, other than 
> that only a single thread should access a StoreScanner at any given time.
> So replaced updateReaders() with some code that just indicates to the scanner 
> that the readers should be updated and then make it the using thread's 
> responsibility to do the work.
> The perf improvement from this is staggering. I am seeing somewhere around 3x 
> scan performance improvement across all scenarios.
> Now, the hard part is to reason about whether this is 100% correct. I ran 
> TestAtomicOperation and TestAcidGuarantees a few times in a loop, all still 
> pass.
> Will attach a sample patch.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Reply via email to