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

Jacob LeBlanc commented on HBASE-23066:
---------------------------------------

Thanks for taking a look at this!

I have not tested on our cluster yet. Our production cluster is the one hitting 
performance problems after compaction and given that EMR is a managed service 
where I'm not exactly sure what is being deployed (does Amazon customize any 
part of the server jar?) I need to somehow verify that replacing the class 
files in the jar with my patched versions isn't going to cause any harm before 
trying the patch on that cluster. I'll try patching on a test environment first 
and I'll also try to get some confirmation through AWS support that I won't be 
overriding customized changes by replacing a class file, particularly the 
HStore class. 

So I'll try to do some testing and get some performance numbers, but it will 
take me a bit of time.

> Allow cache on write during compactions when prefetching is enabled
> -------------------------------------------------------------------
>
>                 Key: HBASE-23066
>                 URL: https://issues.apache.org/jira/browse/HBASE-23066
>             Project: HBase
>          Issue Type: Improvement
>          Components: Compaction, regionserver
>    Affects Versions: 1.4.10
>            Reporter: Jacob LeBlanc
>            Assignee: Jacob LeBlanc
>            Priority: Minor
>             Fix For: 1.5.0, 2.3.0
>
>         Attachments: HBASE-23066.patch, prefetchCompactedBlocksOnWrite.patch
>
>
> In cases where users care a lot about read performance for tables that are 
> small enough to fit into a cache (or the cache is large enough), 
> prefetchOnOpen can be enabled to make the entire table available in cache 
> after the initial region opening is completed. Any new data can also be 
> guaranteed to be in cache with the cacheBlocksOnWrite setting.
> However, the missing piece is when all blocks are evicted after a compaction. 
> We found very poor performance after compactions for tables under heavy read 
> load and a slower backing filesystem (S3). After a compaction the prefetching 
> threads need to compete with threads servicing read requests and get 
> constantly blocked as a result. 
> This is a proposal to introduce a new cache configuration option that would 
> cache blocks on write during compaction for any column family that has 
> prefetch enabled. This would virtually guarantee all blocks are kept in cache 
> after the initial prefetch on open is completed allowing for guaranteed 
> steady read performance despite a slow backing file system.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to