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-9869) Optimize HConnectionManager#getCachedLocation
Date Mon, 18 Nov 2013 08:33:21 GMT

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

Nicolas Liochon commented on HBASE-9869:
----------------------------------------

bq. we're short of memory so we clear the cache in order to do more work if we need the cached
data again
That's exactly that was happening, and that's why we went from 114s to 72s with the patch.
I guess that protobuf added a lot of pressure on the GC, hence this behavior (but I've done
the test with the latest trunk, it includes a lot of cleanup already).

I think that the right pattern is to have the structure as small as possible,  to make it
fit into the processor cache. With all these references all over the place it's difficult
to know exactly how it's going to behave.

bq. I thought HRI only had a table name, not a TableName? We did a load of work to make it
so HRI didn't have a HTD; would be a shame to go back there
There is an attribute "TableName" in HRI, and createRegionName copy the "table name" in another
attribute "regionName": so we store it twice... I will see if I can remove it.




> Optimize HConnectionManager#getCachedLocation
> ---------------------------------------------
>
>                 Key: HBASE-9869
>                 URL: https://issues.apache.org/jira/browse/HBASE-9869
>             Project: HBase
>          Issue Type: Bug
>          Components: Client
>    Affects Versions: 0.98.0, 0.96.0
>            Reporter: Nicolas Liochon
>            Assignee: Nicolas Liochon
>             Fix For: 0.98.0, 0.96.1
>
>         Attachments: 6869.v4.patch, 9869.v1.patch, 9869.v1.patch, 9869.v2.patch
>
>
> It javadoc says: "TODO: This method during writing consumes 15% of CPU doing lookup".
This is still true, says Yourkit. With 0.96, we also spend more time in these methods. We
retry more, and the AsyncProcess calls it in parallel.
> I don't have the patch for this yet, but I will spend some time on it.



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

Mime
View raw message