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

Jean-Daniel Cryans commented on HBASE-8171:
-------------------------------------------

We had a longish discussion about this too here: 
https://issues.apache.org/jira/browse/HBASE-6841

My opinion is that pre-fetching is bad for most use cases the way it is 
implemented and I prefer to run without it in production.
                
> Perf issue with multiple client threads trying to prefetch Region Cache from 
> META
> ---------------------------------------------------------------------------------
>
>                 Key: HBASE-8171
>                 URL: https://issues.apache.org/jira/browse/HBASE-8171
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 0.89-fb, 0.94.3, 0.94.5
>            Reporter: Amitanand Aiyer
>            Assignee: Amitanand Aiyer
>
> HBaseClient maintains a cache of Regions to region locations that gets 
> cleared whenever the RS that the client talks to is unresponsive.
> This will result in the Client having to talk to META to fetch the region 
> location before doing the get/put.
> https://issues.apache.org/jira/browse/HBASE-2468 introduces the feature to 
> prewarm the cache, where the client gets some rows from META to warm the 
> cache.
> This is a costly operation. And,  it looks like all client threads that block 
> on the regionLockObject, will go in and do the cache warmup; although the 
> cache might have been already warmed up by an earlier thread. 
> When there is a network issue going on, we see lots of Client threads 
> blocking in locateRegionInMeta.
> The fix would be to check the cache again; before we do the prefetch after 
> grabbing the lock. Currently, the client threads look in the cache at the 
> begining of the method. But a lot could have changed while waiting for the 
> regionLockObject.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to