[
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)
