hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicolas Liochon (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-9976) Don't create duplicated TableName objects
Date Sat, 16 Nov 2013 13:27:24 GMT

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

Nicolas Liochon commented on HBASE-9976:
----------------------------------------

bq.  Did you figure your sync issue?
I'm on it. I'm looking at the root cause: why a change in TableName impacts the performance.

Partly, there is no root cause: the performances varies a lot it seems.
But as well, the code in pretch / metaScan  expects the underlying layers to be more efficient
than they actually are.
For example, for the prefectch it does:
- a first remote call to get the "rowOrBefore"
- then creates a full HRegionInfo object, including a tableName, just to get the region startKey
- then the actual call to prefetch the other regions

I can't easily optimize this, because rowOrBefore returns a byte array to be unprotobuffed.
The solution I see is using the reverseScan: this would remove the need for the first call,
so all this code would just go away.

Still digging...

> Don't create duplicated TableName objects
> -----------------------------------------
>
>                 Key: HBASE-9976
>                 URL: https://issues.apache.org/jira/browse/HBASE-9976
>             Project: HBase
>          Issue Type: Bug
>          Components: Client, regionserver
>    Affects Versions: 0.98.0, 0.96.0
>            Reporter: Nicolas Liochon
>            Assignee: Nicolas Liochon
>             Fix For: 0.98.0, 0.96.1
>
>         Attachments: 9976.v1.patch
>
>
> A profiling show that the table name is reponsible for 25% of the memory needed to keep
the region locations. As well, comparisons will be faster if two identical table names are
a single java object.



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

Mime
View raw message