hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anoop John <anoop.hb...@gmail.com>
Subject Re: [HBase] dummy cached location when batch insert result in bad performances.
Date Mon, 04 Mar 2013 16:28:09 GMT
The guide explains it well..  The region moves across RSs and splits of
region will cause the location cache(at client) to be stale and it will
look into META again.  The memory flush/compaction and all will not make it
to happen. When there is a change for the META entry for a region, the
location cache can become stale.   Can you check the logs at RS side and
Master side?  Lot of region movements happening?  Or may be lot of splits?
You table is presplit ?


On Mon, Mar 4, 2013 at 4:04 PM, <samuel_hsieh@tsmc.com> wrote:

> Dear experts,
> We met a performance issue when batch insert HBase that our client met
> several "cached location" randomly during batch insert. We would like to
> know when will hbase client trigger cached location again, is it related to
> region split. merged or move or related to memory flush or other event? Are
> there any better configuration to enhance the cached location performance
> if it's a necessary behavior inside hbase? Thanks
> In HBase-The definitive guide, page#346, it wrote:
> Although clients cache region locations, there is an initial need to figure
> out where to
> send requests when looking for a specific row key—or when the cache is
> stale and a
> region has since been split, merged, or moved. The client library uses a
> recursive discovery
> process moving up in the hierarchy to find the current information. It asks
> the
> corresponding region server hosting the matching .META. region for the
> given row key
> and retrieves the address. If that information is invalid, it backs out,
> asking the root
> table where the .META. region is. Eventually, if all else fails, it has to
> do a read of the
> ZooKeeper node to find the root table region.
> Best Regards.
> Sam
>  ---------------------------------------------------------------------------
>                                                          TSMC PROPERTY
>  This email communication (and any attachments) is proprietary information
>  for the sole use of its
>  intended recipient. Any unauthorized review, use or distribution by anyone
>  other than the intended
>  recipient is strictly prohibited.  If you are not the intended recipient,
>  please notify the sender by
>  replying to this email, and then delete this email and any copies of it
>  immediately. Thank you.
>  ---------------------------------------------------------------------------

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message